00:42:11 <alanc> https://sourceware.org/git/?p=binutils-gdb.git;a=blame;f=bfd/elf.c;h=a82a1dd60a6bd018c2ac471b63759aa9e1b1ecf4;hb=32778522c7d8777803c88684b8e428ee729f0b22 suggests the code around there hasn't changed in a few years though
00:52:00 <richlowe> yeah, I started from the first message I saw, read the comment and went "Huh?"
00:52:07 <richlowe> and then scrolled back to where we were already screwed
04:24:11 <sommerfeld> richlowe: if all else fails, git bisect between 2.39 and 2.40 might at least generate a suspect.
08:50:29 <jperkin> 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
10:59:54 <grumb> Huge group see you in a bit
11:26:06 <grumb> Chose this cos said easier. In order to learn Unix commands.
12:11:42 <tsoome_> hello
12:13:10 <grumb> Hi all Tsoome especially
12:13:44 <tsoome_> .oO
12:29:41 <denk> tsoome_: are you surprised you are a big star? next stage is a surernova :)
12:29:56 <tsoome_> im no star:)
12:30:05 <denk> then black hole aka /dev/null
12:32:10 <grumb> Better sunny than starry
12:37:42 <tsoome_> true
12:37:55 <tsoome_> hm, i have tail again.
15:18:36 <gitomat> [illumos-gate] 15355 zfstest: rwx_node() should use true instead of ls -- Toomas Soome <tsoome⊙mc>
15:38:14 <danmcd> Attention distro managers:  https://mta.openssl.org/pipermail/openssl-announce/2023-January/000248.html
15:50:10 <tsoome> and the whell is running again:)
15:50:14 <tsoome> wheel*
17:37:51 <igork> hi all, could someone try to check on latest illumos with installed but not run zone:
17:38:05 <igork> chroot /zones/zbu1/root id
17:38:13 <igork> what you can see ?
17:38:58 <igork> danmcd: thx
17:48:13 <richlowe> jperkin: I have a fix, and when it's a bit better I'll send it out, it's all good.
18:01:25 <nahamu> jperkin: oof. I hope you're feeling a bit better or if not that you start feeling better soon!
18:33:30 <jclulow> igork: You might need to install an illumos-based system and check.
19:48:30 <richlowe> is there a way to make cstyle happy about c99 cpp stringification?
19:48:32 <richlowe> andyf?
19:48:41 <richlowe> common/elfdump.c: 885: preprocessor statement not in column 1
19:48:51 <richlowe> that's 'cos it's not a pre-processor statement, exactly...
19:50:02 <tsoome> talking of cstyle... https://code.illumos.org/c/illumos-gate/+/2082 :)
19:50:03 <fenix> → CODE REVIEW 2082: 14596 cstyle should allow empty increment with for loop (NEW) | https://www.illumos.org/issues/14596
19:52:29 <richlowe> tsoome: what happens if you try to read a flexible member in D? I don't remember if tries to bounds check
19:52:46 <richlowe> or if there's any knock-on from it being void-y
19:53:53 <tsoome> um, only automatic check could be based on structure size - if so, you would get error.
19:54:52 <tsoome> I guess, the easiest check would be with ncache_t from sys/dnlc.h
20:00:01 <richlowe> the gstrip bug is #15361 (fenix?) if distribution folks want something to watch (andyf, jperkin, etc.)
20:00:02 <fenix> BUG 15361: ld doesn't fill out PT_DYNAMIC sufficiently for binutils 2.40 (In Progress)
20:00:02 <fenix> ↳ https://www.illumos.org/issues/15361
20:10:32 <andyf> richlowe - thanks!
20:18:44 <tsoome> 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
20:19:49 <tsoome> thats from referencing char name[]. 
20:20:06 <richlowe> seems unfortunate?
20:20:36 <richlowe> you'd need someone smarter than me to tell though.
20:25:45 <tsoome> oh, it was my bad, NULL pointer:D
20:29:24 <toasterson> There seems to be a joke about Java and D and Nullpointers in there. I just cant get to it
20:30:47 <Luser0> @toasterson - D language is a joke to begin with ... Jave is rich in something... caffeine?
20:31:16 <Luser0> Have you read the D language compiler specs?
20:31:38 <toasterson> Dtrace script is also called D
20:31:59 <Luser0> Is that a typescript extension?
20:32:24 <toasterson> Nope, the dynamic tracing framework
20:32:51 <toasterson> http://dtrace.org/blogs/about/
20:33:00 <Luser0> Good typescript extension name, though. Maybe I should work on it?
20:33:34 <toasterson> hahahha, it might actually improve typescript whne you can use dtrace probes indide of it
20:34:17 <Luser0> The lime in the coconut with the circle gets the square.. with variable scale fonts
20:34:39 <tsoome> 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.
20:34:55 <Luser0> It should really make you see double in VR goggles.
20:35:16 <richlowe> tsoome: not sure how exactly to add that to the tests, but good to know. 
20:36:31 <Luser0> Dtrace says solaris with the other op systems. My guess is solaris elf makes it pop to top
20:38:35 <Luser0> Now I'm reminiscing about the MacPi
20:38:44 <Luser0> Get a slice... of MacPi
20:39:15 <Luser0> MacPi with illumos ... a headache that never stops
20:40:40 <Luser0> Then they built that into those battery slips
20:41:00 <Luser0> A Hot operation... use them for pizza ovens
20:46:20 <tsoome> would be nice if yacc would be LARL(2) :P
20:46:36 <tsoome> LALR(2), even...
20:47:40 <otis> LART? :-o
20:48:29 <tsoome> with RT?
21:21:10 <Luser0> Oh - Dtrace is the Sun tool. I met taht project leader a few weeks before he ... uuh, quit. right. He quit.
21:22:08 <Luser0> They reverted about two months of forward development. But a lot of us still had it.
21:22:16 <toasterson> He does https://oxide.computer/ now
21:22:42 <Luser0> No... not him. When he quit. Uhh ... he quit.
21:23:16 <Luser0> You are probably thinking of the one who worked with Microsoft development integrations.
21:23:28 <toasterson> Ah..... don't know that storry then. But understand the reference
21:23:32 <Luser0> The one before him... or was it two, before him.
21:24:04 <Luser0> Oxide.. the group that made my Vista buy a piece of trash from day one?
21:28:46 <richlowe> I have no idea what's going on, but it all seems innacurate.
21:31:48 <sommerfeld> 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...
21:31:55 <andyf> I am glad it's not just me who is confused!
21:32:16 <andyf> sommerfeld - yes, it originated in SmartOS
21:32:26 <andyf> and was pulled over to OmniOS as part of the lx brand
21:32:49 <andyf> and then used for more things thereafter
21:33:01 <Luser0> Kowala was a principal at Ix? Or am I mistaken?
21:33:12 <andyf> It very probably should be upstreamed
21:34:59 <sommerfeld> 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.
21:35:12 <Luser0> Should I do the LiSP joke?
21:36:08 <andyf> I'm not aware of any prior attempts. I've never tried to upstream it from OmniOS, I don't know about SmartOS - @danmcd ?
21:36:57 <tsoome> (Luser0) no:P 
21:37:04 <Luser0> SmartOS had the gmod kern - if I recall correctly. But I will still do the how can it be upstreamed without a PaDL?
21:37:10 <Luser0> Too late.
21:40:52 <danmcd> @andyf -> No attempts to upstream ever AFAICT.  And @sommerfeld you mean 'global-nic' right?
21:41:45 <danmcd> I don't know why it wasn't upstreamed (I didn't know it was taken for OmniOS until today, but it makes sense).
21:41:53 <andyf> Well, you did it :)
21:42:15 <sommerfeld> yes, global-nic
21:42:48 <danmcd> Oh shit... I pulled it in with LX.
21:42:55 <sommerfeld> https://github.com/omniosorg/illumos-omnios/commit/16f7c85024c4ff3904ed5271608bcff7c1af37d2
21:42:57 <andyf> 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.
21:43:00 <danmcd> Sorry, forgot about that.
21:43:02 <toasterson> sommerfeld: pr to the brand code or a seperate repo very welcome for OI btw :)
21:43:16 <andyf> Now those I /have/ tried to upstream a couple of times
21:44:01 <andyf> danmcd - yep, although I think it was collateral rather than completely necessary, but I'm very glad you did.
21:44:27 <danmcd> I tried not to pull in things unless it was necessary for LX, but those early commits were hard to tease apart.
21:45:12 <sommerfeld> toasterson: I may be headed in that direction once the groundwork is there in illumos-gate
21:47:00 <toasterson> sommerfeld: I did these zonebrands and a vmadm wrapper in rust recently to get a similar result. https://github.com/OpenFlowLabs/aurora-opencloud/tree/main/opczone Need to work on it afte I get some progress into the build tools work
21:49:27 <Luser0> Aurora was used for flash tools by somebody? Can't recall what OEM
21:52:31 <toasterson> Was there a way to include other manifests in a package manifest during mogirfy?
21:53:06 <andyf> There's an <include> action
21:53:58 <toasterson> Cool, let's see if it works for my purposes.
22:01:13 <toasterson> Ah, perfect -I includedir exists in pkgmogrify
22:01:23 <sommerfeld> <include> has worked when I've needed it.
22:08:46 <sommerfeld> andyf: oh, and thanks for the code reviews.
22:12:56 <sommerfeld> pbchk is warning about #pragma ident in libc/.../closefrom.c; should I nuke it now or wait for tsoome's sweep to get it?
22:15:27 <richlowe> nuke it
22:17:42 <danmcd> I'm sure tsoome won't mind not having to do one file.  :)
22:19:52 <tsoome> absolutely nuke it.
22:20:07 <sommerfeld> gone.
22:20:50 <richlowe> I seem to recall the vnic magic/namespace stuff not being great in a non-smartos environment 
22:21:20 <alanc> 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 https://illumos.org/opensolaris/bugdb/bug.html#!1138133
22:21:21 <fenix> → OpenSolaris issue 1138133: Excessive kernel time with Xterminal loads (Fix Delivered)
22:21:42 <alanc> (not xterms, but X terminal devices, in the days before Sun Rays)
22:22:10 <danmcd> 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.
22:22:16 <alanc> You are allowed exactly one guess as to the identity of the "Adrian" named in said bug
22:22:37 <danmcd> HA!
22:23:46 <richlowe> you definitely should add comments to the enter/exit pair
22:24:16 <alanc> yeah, I'm sure you're neither the first nor the last person to wonder about that
22:25:14 <danmcd> It won't be part of 14892 however. (The pollwakeup mutex pair was an innocent bystander in a deadlock.)
22:26:13 <richlowe> doesn't stop you describing it! 
22:27:39 <richlowe> (and if you find me an advocate who disagrees, I will even argue with them on your behalf)
22:39:14 <andyf> sommerfeld - you're welcome.
22:41:55 <richlowe> alanc: some days, rarely, I miss my old xterminal.
22:42:35 <richlowe> 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.
22:42:43 <richlowe> assuming you can find a linux that still uses X
22:43:21 <alanc> I was amused at the pics on mastodon today of an iPod nano running Wayland
22:43:51 <toasterson> there is always xwayland :)
23:08:56 <sommerfeld> andyf:  "Almost atomic" sounds like asking for trouble, though.   
23:14:40 <jclulow> I stand with richlowe and will fight anyone that doesn't want more comments :P
23:16:29 <jclulow> FWIW, I think zone brands managing ephemeral VNICs is valuable, and I'm sure we can get that in somehow or other.
23:18:31 <toasterson> 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
23:18:31 <toasterson> and namespaced link names so I can get rid of my nicname friendly rand_str function :)
23:19:08 <jclulow> So I think it is not unreasonable to separate brand-managed NIC lifecycle from per-zone namespacing
23:19:29 <jclulow> I think the latter has a lot more open questions
23:19:54 <jclulow> And even if we had namespacing support, it would not be required that one used it with brand-managed NICs anyway
23:21:04 <toasterson> true, what i like however in smartos and omnios are the per nic data entries
23:21:15 <toasterson> ind the schema of the zones
23:21:17 <jclulow> 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
23:21:40 <jclulow> depending on what storage you mean of course
23:22:11 <toasterson> the capability to define properties of the zone via zoneadm per nic
23:22:24 <toasterson> and that syntax and xml extensions
23:22:40 <jclulow> Yeah I think that's all attributes on the `net` object right
23:22:47 <jclulow> in the zonecfg XML files
23:22:47 <toasterson> yep
23:23:13 <toasterson> also some are children elements but yeah they are extensions of the net object
23:23:54 <jclulow> Yeah so that stuff would need upstreaming
23:24:21 <jclulow> 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_
23:24:30 <jclulow> So that each one doesn't need to reimplement or copy-paste it
23:25:07 <toasterson> fair. although my brand code is in rust so I would need to port that anyway
23:25:51 <toasterson> a feature that i am missing in brandcode though is something like svcprop for zone configs
23:26:25 <jclulow> As in, a source of metadata that you can consume from inside the zone?
23:26:51 <toasterson> as in a utility I can call from the brand code to get the data about the zone I need
23:27:06 <jclulow> Oh, so not inside the zone
23:27:20 <toasterson> no, but now that you mention it....
23:28:03 <toasterson> 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
23:28:19 <toasterson> or make that configurable in config.xml
23:28:55 <andyf> 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.
23:29:20 <jclulow> So we actually tell you the path of the zone XML file as an argument to various brand hook entrypoints
23:29:26 <toasterson> true, that is actually better, since that can be read-only
23:29:28 <andyf> and alternatively there is some brand-specific data you can set in the kernel and then retrieve from inside the zone
23:29:50 <andyf> That's how things like allowed-address work
23:30:19 <jclulow> Yeah, I think it depends on what you need to store, and who is consuming it, etc
23:30:33 <jclulow> The brand can always drop whatever file it wants into the zone root during install or even boot
23:30:40 <toasterson> I have never seen samples where the XML files is provided as arguments.
23:31:14 <toasterson> andyf: what are the interfaces to that storage capability?
23:31:18 <jclulow> The "verify_cfg" entrypoint takes the XML for instance
23:31:47 <jclulow> So that you can check properties and fail verify before commit in zonecfg
23:32:19 <andyf> zone_{set,get}attr() 
23:32:54 <toasterson> Well, in that case all the entrypoints I was using don't get it like install :)
23:34:48 <jclulow> One of the challenges is that this stuff is not really Committed as far as I know
23:35:15 <jclulow> 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
23:35:32 <toasterson> It's even mostly undocumented
23:35:34 <toasterson> query_cfg for example has no documentation
23:35:45 <jclulow> Yeah
23:35:55 <jclulow> I spent some time in the source
23:36:02 <jclulow> when I was writing the brand for OXide
23:36:51 <jclulow> FWIW, I think the NIC lifecycle stuff should probably be an extension to the virtual platform (see zoneadmd/vplat.c)
23:36:55 <andyf> 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.
23:37:15 <jclulow> Things like configure_one_interface() and add_datalink() are in there, etc, already
23:37:45 <jclulow> There is a lot of code in here for shoving NICs that you have already provisioned into the zone correctly
23:37:46 <toasterson> jclulow: it's definetly a vplat job.
23:38:03 <jclulow> So it just needs to learn how to be responsible for the provisioning on its own
23:38:15 <jclulow> Then brands will get it for free
23:38:42 <toasterson> yep. it will need to do so during install. or at least remove that warning about unconfigured nics
23:39:01 <toasterson> smartos does it during boot though
23:39:32 <jclulow> Yeah I'm not sure which is better there.  Perhaps the brand could make a decision.
23:40:25 <toasterson> install seems to early for a couple usescases. boot is the last time you can do it so it's the more logical choice
23:40:35 <toasterson> before pushing it is the last chance to be more precise
23:40:53 <jclulow> If you do it at install time, then at least you know it's going to be able configure it at that moment
23:41:09 <jclulow> But also it means the VNIC probably sits around consuming NIC classification resources etc, which is not great
23:41:19 <jclulow> But doing it at boot means it could fail to do it at boot
23:41:28 <jclulow> which might be sad depending on what your expectations are
23:41:42 <toasterson> I am less concerned about that failure due to verify
23:42:15 <jclulow> verify is unlikely to catch collisions
23:42:21 <jclulow> or inadequate resources
23:42:48 <toasterson> inadequate resources does not seem to be a problem for smartos
23:43:06 <toasterson> collisions is more a question of rand function and maybe one retry
23:45:24 <jclulow> I don't think there's any facility for random or retry in the way the properties work today
23:45:38 <jclulow> It looks like if you provide global-nic, and physical, we're going to use physical verbatim to create the VNIC
23:46:10 <jclulow> You could instead specify maybe just the _name_ portion of the VNIC and have the framework pick the next free ppa number
23:46:24 <jclulow> But that would be a new attribute on the net thing at least
23:47:08 <toasterson> I meant something similar to what I do of just picking a sufficiently random string as name and adding a 0 to it
23:47:22 <toasterson> but getting the ppa number is good aswell :)
23:47:28 <jclulow> Oh sure, but that's not something the brand can help with
23:47:44 <jclulow> or vplat etc
23:48:10 <jclulow> But yeah if you already have a global uniqueness strategy that seems fine
23:49:20 <toasterson> was more of a suggestion for whoever looks at the upstreaming of that functionality.
23:50:17 <toasterson> since we seperate but also want the namespaces we only need the uniqueness strategy temporarily