sourceware.org/git/?p=binutils-gdb.…522c7d8777803c88684b8e428ee729f0b22 suggests the code around there hasn't changed in a few years though

yeah, I started from the first message I saw, read the comment and went "Huh?"

and then scrolled back to where we were already screwed

richlowe: if all else fails, git bisect between 2.39 and 2.40 might at least generate a suspect.

richlowe: yeh sorry I just didn't have time to be helpful for upstream, already spent hours through a weekend with covid to get pkgsrc back up and running

Huge group see you in a bit

Chose this cos said easier. In order to learn Unix commands.

hello

Hi all Tsoome especially

.oO

tsoome_: are you surprised you are a big star? next stage is a surernova :)

im no star:)

then black hole aka /dev/null

Better sunny than starry

true

hm, i have tail again.

[illumos-gate] 15355 zfstest: rwx_node() should use true instead of ls -- Toomas Soome <tsoome⊙mc>

Attention distro managers: mta.openssl.org/pipermail/openssl-announce/2023-January/000248.html

and the whell is running again:)

wheel*

hi all, could someone try to check on latest illumos with installed but not run zone:

chroot /zones/zbu1/root id

what you can see ?

danmcd: thx

jperkin: I have a fix, and when it's a bit better I'll send it out, it's all good.

jperkin: oof. I hope you're feeling a bit better or if not that you start feeling better soon!

igork: You might need to install an illumos-based system and check.

is there a way to make cstyle happy about c99 cpp stringification?

andyf?

common/elfdump.c: 885: preprocessor statement not in column 1

that's 'cos it's not a pre-processor statement, exactly...

talking of cstyle... code.illumos.org/c/illumos-gate/+/2082 :)

→ CODE REVIEW 2082: 14596 cstyle should allow empty increment with for loop (NEW) | illumos.org/issues/14596

tsoome: what happens if you try to read a flexible member in D? I don't remember if tries to bounds check

or if there's any knock-on from it being void-y

um, only automatic check could be based on structure size - if so, you would get error.

I guess, the easiest check would be with ncache_t from sys/dnlc.h

the gstrip bug is #15361 (fenix?) if distribution folks want something to watch (andyf, jperkin, etc.)

BUG 15361: ld doesn't fill out PT_DYNAMIC sufficiently for binutils 2.40 (In Progress)

↳ illumos.org/issues/15361

richlowe - thanks!

richlowe: dtrace: error on enabled probe ID 1 (ID 8207: fbt:genunix:dnlc_search:return): invalid address (0x24) in action #2 at DIF offset 12

thats from referencing char name[].

seems unfortunate?

you'd need someone smarter than me to tell though.

oh, it was my bad, NULL pointer:D

There seems to be a joke about Java and D and Nullpointers in there. I just cant get to it

@toasterson - D language is a joke to begin with ... Jave is rich in something... caffeine?

Have you read the D language compiler specs?

Dtrace script is also called D

Is that a typescript extension?

Nope, the dynamic tracing framework

Good typescript extension name, though. Maybe I should work on it?

hahahha, it might actually improve typescript whne you can use dtrace probes indide of it

The lime in the coconut with the circle gets the square.. with variable scale fonts

richlowe dnlc_search:return len: 8 name: .lesshsQ from printf("len: %d name: %.*s\n", this->ncp->namlen, this->ncp->namlen, stringof(this->ncp->name)); and 'name' is flexible member of ncache_t.

It should really make you see double in VR goggles.

tsoome: not sure how exactly to add that to the tests, but good to know.

Dtrace says solaris with the other op systems. My guess is solaris elf makes it pop to top

Now I'm reminiscing about the MacPi

Get a slice... of MacPi

MacPi with illumos ... a headache that never stops

Then they built that into those battery slips

A Hot operation... use them for pizza ovens

would be nice if yacc would be LARL(2) :P

LALR(2), even...

LART? :-o

with RT?

Oh - Dtrace is the Sun tool. I met taht project leader a few weeks before he ... uuh, quit. right. He quit.

They reverted about two months of forward development. But a lot of us still had it.

He does oxide.computer now

No... not him. When he quit. Uhh ... he quit.

You are probably thinking of the one who worked with Microsoft development integrations.

Ah..... don't know that storry then. But understand the reference

The one before him... or was it two, before him.

Oxide.. the group that made my Vista buy a piece of trash from day one?

I have no idea what's going on, but it all seems innacurate.

anyone familiar with the history of omnios's zonecfg global-net feature (and why it wasn't pushed upstream into illumos?) went down a bit of a rabbit hole trying out bhyve on openindiana, noticed its old version of the bhyve brand code, looked at omnios's and...

I am glad it's not just me who is confused!

sommerfeld - yes, it originated in SmartOS

and was pulled over to OmniOS as part of the lx brand

and then used for more things thereafter

Kowala was a principal at Ix? Or am I mistaken?

It very probably should be upstreamed

ok, wanted a read of whether it was just lack of anyone getting around to it vs. some prior attempts that had run into opposition.

Should I do the LiSP joke?

I'm not aware of any prior attempts. I've never tried to upstream it from OmniOS, I don't know about SmartOS - @danmcd ?

(Luser0) no:P

SmartOS had the gmod kern - if I recall correctly. But I will still do the how can it be upstreamed without a PaDL?

Too late.

@andyf -> No attempts to upstream ever AFAICT. And @sommerfeld you mean 'global-nic' right?

I don't know why it wasn't upstreamed (I didn't know it was taken for OmniOS until today, but it makes sense).

Well, you did it :)

yes, global-nic

Oh shit... I pulled it in with LX.

The thing is, that SmartOS has a lot of other things in this area that allow things like almost atomically creating a VNIC in a zone, and the link namespace being per-zone etc.

Sorry, forgot about that.

sommerfeld: pr to the brand code or a seperate repo very welcome for OI btw :)

Now those I /have/ tried to upstream a couple of times

danmcd - yep, although I think it was collateral rather than completely necessary, but I'm very glad you did.

I tried not to pull in things unless it was necessary for LX, but those early commits were hard to tease apart.

toasterson: I may be headed in that direction once the groundwork is there in illumos-gate

sommerfeld: I did these zonebrands and a vmadm wrapper in rust recently to get a similar result. github.com/OpenFlowLabs/aurora-opencloud/tree/main/opczone Need to work on it afte I get some progress into the build tools work

Aurora was used for flash tools by somebody? Can't recall what OEM

Was there a way to include other manifests in a package manifest during mogirfy?

There's an <include> action

Cool, let's see if it works for my purposes.

Ah, perfect -I includedir exists in pkgmogrify

<include> has worked when I've needed it.

andyf: oh, and thanks for the code reviews.

pbchk is warning about #pragma ident in libc/.../closefrom.c; should I nuke it now or wait for tsoome's sweep to get it?

nuke it

I'm sure tsoome won't mind not having to do one file. :)

absolutely nuke it.

gone.

I seem to recall the vnic magic/namespace stuff not being great in a non-smartos environment

danmcd: amusingly it appears the pollwakeup() code to do the tryenter/enter/exit first appeared in Solaris 2.4 to make serving a bunch of Xterminals scale better under illumos.org/opensolaris/bugdb/bug.html#!1138133

→ OpenSolaris issue 1138133: Excessive kernel time with Xterminal loads (Fix Delivered)

(not xterms, but X terminal devices, in the days before Sun Rays)

alanc: On-list from Dan Cross and off-list from multiple others has convinced me that the paired mutex_{enter,exit}(&same_lock) is not something dumb.

You are allowed exactly one guess as to the identity of the "Adrian" named in said bug

HA!

you definitely should add comments to the enter/exit pair

yeah, I'm sure you're neither the first nor the last person to wonder about that

It won't be part of 14892 however. (The pollwakeup mutex pair was an innocent bystander in a deadlock.)

doesn't stop you describing it!

(and if you find me an advocate who disagrees, I will even argue with them on your behalf)

sommerfeld - you're welcome.

alanc: some days, rarely, I miss my old xterminal.

though it's not like a raspberry pi (before the price crazyness) wouldn't do the same job at a tiny fraction of the price.

assuming you can find a linux that still uses X

I was amused at the pics on mastodon today of an iPod nano running Wayland

there is always xwayland :)

andyf: "Almost atomic" sounds like asking for trouble, though.

I stand with richlowe and will fight anyone that doesn't want more comments :P

FWIW, I think zone brands managing ephemeral VNICs is valuable, and I'm sure we can get that in somehow or other.

I can manage ephemeral vnics already! But I would like to have some(better) way to describe the data then to dump a json file next to the zone

and namespaced link names so I can get rid of my nicname friendly rand_str function :)

So I think it is not unreasonable to separate brand-managed NIC lifecycle from per-zone namespacing

I think the latter has a lot more open questions

And even if we had namespacing support, it would not be required that one used it with brand-managed NICs anyway

true, what i like however in smartos and omnios are the per nic data entries

ind the schema of the zones

I think if we provide system-wide NIC management facilities that brands can consume, we would store the required data in either some zoneadm/libzonecfg-managed data files, or we would perhaps even delegate the storage to dladm

depending on what storage you mean of course

the capability to define properties of the zone via zoneadm per nic

and that syntax and xml extensions

Yeah I think that's all attributes on the `net` object right

in the zonecfg XML files

yep

also some are children elements but yeah they are extensions of the net object

Yeah so that stuff would need upstreaming

And hopefully in a way where we can provide the core of the delegation and lifecycle management in common code that brands can just _use_

So that each one doesn't need to reimplement or copy-paste it

fair. although my brand code is in rust so I would need to port that anyway

a feature that i am missing in brandcode though is something like svcprop for zone configs

As in, a source of metadata that you can consume from inside the zone?

as in a utility I can call from the brand code to get the data about the zone I need

Oh, so not inside the zone

no, but now that you mention it....

at least defining a default xml location so it could be used inside the zone aswell and the brand can drop the xml in if it wants

or make that configurable in config.xml

Well you can easily mount the .xml into the zone root if you want. I think that's what the OI bhyve brand does actually.

So we actually tell you the path of the zone XML file as an argument to various brand hook entrypoints

true, that is actually better, since that can be read-only

and alternatively there is some brand-specific data you can set in the kernel and then retrieve from inside the zone

That's how things like allowed-address work

Yeah, I think it depends on what you need to store, and who is consuming it, etc

The brand can always drop whatever file it wants into the zone root during install or even boot

I have never seen samples where the XML files is provided as arguments.

andyf: what are the interfaces to that storage capability?

The "verify_cfg" entrypoint takes the XML for instance

So that you can check properties and fail verify before commit in zonecfg

zone_{set,get}attr()

Well, in that case all the entrypoints I was using don't get it like install :)

One of the challenges is that this stuff is not really Committed as far as I know

So as part of considering what you need to implement a brand, we should consider which bits are stable and can be used by out-of-tree brands, etc

It's even mostly undocumented

query_cfg for example has no documentation

Yeah

I spent some time in the source

when I was writing the brand for OXide

FWIW, I think the NIC lifecycle stuff should probably be an extension to the virtual platform (see zoneadmd/vplat.c)

Yeah, me too when I was doing the 'illumos' brand for omnios, and trying to find out how datasets become visible to the zone, etc.

Things like configure_one_interface() and add_datalink() are in there, etc, already

There is a lot of code in here for shoving NICs that you have already provisioned into the zone correctly

jclulow: it's definetly a vplat job.

So it just needs to learn how to be responsible for the provisioning on its own

Then brands will get it for free

yep. it will need to do so during install. or at least remove that warning about unconfigured nics

smartos does it during boot though

Yeah I'm not sure which is better there. Perhaps the brand could make a decision.

install seems to early for a couple usescases. boot is the last time you can do it so it's the more logical choice

before pushing it is the last chance to be more precise

If you do it at install time, then at least you know it's going to be able configure it at that moment

But also it means the VNIC probably sits around consuming NIC classification resources etc, which is not great

But doing it at boot means it could fail to do it at boot

which might be sad depending on what your expectations are

I am less concerned about that failure due to verify

verify is unlikely to catch collisions

or inadequate resources

inadequate resources does not seem to be a problem for smartos

collisions is more a question of rand function and maybe one retry

I don't think there's any facility for random or retry in the way the properties work today

It looks like if you provide global-nic, and physical, we're going to use physical verbatim to create the VNIC

You could instead specify maybe just the _name_ portion of the VNIC and have the framework pick the next free ppa number

But that would be a new attribute on the net thing at least

I meant something similar to what I do of just picking a sufficiently random string as name and adding a 0 to it

but getting the ppa number is good aswell :)

Oh sure, but that's not something the brand can help with

or vplat etc

But yeah if you already have a global uniqueness strategy that seems fine

was more of a suggestion for whoever looks at the upstreaming of that functionality.

since we seperate but also want the namespaces we only need the uniqueness strategy temporarily