10:34:26 <toasterson> tsoome are you working with a loader build that has https://wiki.freebsd.org/FlattenedDeviceTree enabled?
12:25:38 <Luser0> Is there a roadmap for Illumos?
12:26:37 <Luser0> Also, is the name ill-um-os or il-lum-os?  Both?
12:27:25 <jzu_> it comes from illuminati, as a pun to Sun.. so it's illum-os most likely.
12:27:57 <Luser0> Then there are illum-putians?
12:28:17 <Luser0> Taht would be a giant step on the roadmap
12:34:22 <Luser0> Would it be to challenging to ask if a multi-arch concept for Illumos was considered?
12:34:30 <Luser0> **too
12:34:36 <nbjoerg> what do you mean with multi-arch
12:34:55 <jzu_> There used to be SPARC but I think that was dropped quite recently?
12:35:24 <Luser0> Seems to be a x86 only structure - or have I guessed wrong. I could go look at the open source.
12:35:31 <qyliss> people are working on ARM
12:35:33 <Luser0> But that's like reading the manual.
12:35:42 <qyliss> and yeah, there was SPARC until very recently
12:36:00 <andyf> There still are SPARC distributions of illumos
12:36:20 <Luser0> Well, Sparc went without mentioning... are there working Sparc boards? not many, I suspect
12:47:28 <Luser0> IPD #36 looks interesting. Any action on relegating 32 bits to the heap of history?
12:47:49 <Luser0> I prefer 12 bit computing platforms, usually.
12:49:10 <Luser0> If you have not debugged 12 bit machine code from a 16 bit Sun, you haven't been anywhere.
13:11:04 <toasterson> Luser0: We have x86 some SPARC and are working on ARMv8 and Risc-V as platforms.
13:19:18 <Luser0> Who makes a Risc-V?
13:19:39 <toasterson> A Japanese fellow made a port
13:19:52 <toasterson> we are in the works of integrating it together with the ARM port
13:20:02 <Luser0> I meant the hardware. Is it still produced?
13:20:18 <qyliss> RISC-V is extremely new
13:20:33 <qyliss> it's more that hardware is not widely available yet than any sort of "still"
13:20:36 <toasterson> It's mostly a University piece and has a loyal Open source followship
13:20:43 <Luser0> I sorry ... don't let the Finnish know I spouted.
13:21:04 <qyliss> but you can buy RISC-V hardware from e.g. https://www.sifive.com/
13:23:11 <Luser0> That's why they'd rather have South Americans banning me from IRC than let that whale float, down here, where we all float.
13:25:47 <Luser0> Too bad I wasn't a financial whale. But I am putting on pounds... I may qualify soon. Just call me Jabba!
13:27:10 <Luser0> New ice cream flavor. Jabba the Hutt, just add RiscV sprinkles.
13:28:03 <Luser0> The Admiral has been dead awhile, anyway. Huh!.
13:30:30 <qyliss> toasterson: where are the most up to date ARM/RISC-V ports?
13:31:01 <toasterson> https://github.com/richlowe/arm64-gate
13:31:26 <toasterson> thats inluding cross build toolchain and image builder for qemu
13:32:00 <toasterson> I am also working on https://github.com/solarm-project
13:32:08 <qyliss> thanks!
13:32:20 <toasterson> Where I'm gona place my things and distribution work.
13:33:03 <toasterson> Still want to push OI but I will need to redo the buildsystem anyways so I am making it in a language I understand
13:33:05 <andyf> and you can boot a mini ARM omnios today, with https://downloads.omnios.org/media/braich/
13:33:06 <Luser0> Know who does the = Vector data stride L2 prefetcher unit
13:33:08 <toasterson> omnios has begun their integrations aswell, so they will eventually have builds from their tree aswell
13:33:27 <toasterson> andyf: ha, you also went with braich :)
13:33:56 <andyf> It's all building on the work in the arm64-gate branch, but adding more userland packages on top, so it has openssh and so on - and soon, with any luck, `pkg`1
13:34:40 <toasterson> yeah I figured you where blazing towards that end. Which is why I am working myself down to the hardware level ATM
13:46:34 <Luser0> Think that ECX Fabric will ever run on a Windos platform?
13:47:04 <Luser0> Must be why the new chief was selected from the specific chosen.
13:47:06 <andyf> Blazing is generous, especially compared to how much work richlowe is putting in. I need to make time to pick up some more there.
13:48:26 <Luser0> And Stefan Raab has some relationship to Illumos?
13:52:10 <otis> stefan raab of pro7? :-)
13:58:27 <Luser0> Sure, the German news anchor. Not
13:59:09 <Luser0> The cloudfront guy with Braich. Is Braich still changing coordinates?
13:59:46 <toasterson> Braich is derived from the Latin Braccium for Arm :) It's a pun
13:59:59 <toasterson> in Welsh and Irish
14:00:18 <Luser0> No, it's the guy who made us miss Bin Laden and kill his wife and kids, instead.
14:00:41 <Luser0> But he probably doesn't put that on his business card.
14:01:15 <Luser0> He should have taken the poison that Kowala got.
15:00:09 <danmcd> pmooney: and others interested in fenix illumos 14892 --> the bug report mentions dp_cache_poll() needs to not releasef() until it's done with php.  Here's an initial patch attempt (untested):  https://kebe.com/~danmcd/webrevs/14892/dp_pcache_poll-14892.patch
15:00:10 <fenix> BUG 14892: pollhead lifetime too short in signalfd (In Progress)
15:00:10 <fenix> ↳ https://www.illumos.org/issues/14892
15:01:46 <pmooney> danmcd: I was hoping to swing back to that function and do some restructuring, rather than sprinkling releasefd() throughout
15:01:50 <pmooney> it's already hard enough to read as-is
15:02:03 <danmcd> Fair point. 
15:02:19 <pmooney> that function is already at or beyond the breaking point when it comes to complexity
15:03:01 <danmcd> But that patch should cover the cases where php was being used/manipulated AFTER releasef().  It could inform a refactoring.
15:03:23 <pmooney> yeah, I'm aware of what needs to be done
15:03:30 <pmooney> it's a matter of working up the gumption to do it
15:03:37 <pmooney> and deciding what path to take
15:15:31 <danmcd> Oh thank goodness for debug kernels... :)
15:24:04 <danmcd> It tripped on the devpoll dp_pcache_poll() (though why it GPF'ed with an allocated buffer is beyond me).
15:25:41 <pmooney> which did
15:25:54 <pmooney> your patch or the "vanilla" 14892 one?
15:25:58 <toasterson> richlowe is the split of platuart and platmmc soley based on our sources? I am doing research about device tree usage on ARM and it looks to me Hyashi did not get around to it but that it should be one driver configuring itself with device tree
15:26:44 <danmcd> Neither... this is with a stock OmniOS bloody. Next step is to try fixes, and honestly, the devpoll.c one is now first (mostly because it's independent of the 14892 you wrote).
15:27:41 <danmcd> I tripped it with the simple repro program running 8 times concurrently plus a shell script looping through pkills.
15:41:08 <danmcd> Luckily both devpoll and signalfd are standalone modules, making experimentation/replacement easy.
16:56:03 <hpqoeu> what are the expected minimum hardware requirements for an arm port? i don't expect to be able to run it on my first gen pi b+ but on the other hand it would be fun
16:57:09 <toasterson> rpi 4 4gb ram 16gb emmc
16:57:11 <toasterson> no wireless
16:57:25 <toasterson> or qemu
16:58:00 <hpqoeu> bhyve?
16:58:39 <toasterson> we are looking at ampere and rpi at the moment since we have basic rpi compatible drivers. Odroid also has drivers ATM support should increase once we have device trees properly implemented
16:58:54 <jclulow> It should probably work in 2GB of RAM also right 
16:59:10 <toasterson> no bhyve, we use the emulator of qemu
16:59:17 <toasterson> jclulow: currently without IPS yes
16:59:33 <hpqoeu> oh so no vms basically? or at least not hardware accelerated i guess
16:59:43 <jclulow> IPS should be able to work in 2GB of RAM
17:00:12 <toasterson> it's a differnt ISA hpqoeu  so hypervisor support is a new driver
17:00:40 <toasterson> jclulow: well... experience tells no. I am happy to be proven wrong though
17:00:49 <toasterson> helios might with the current amount of packages
17:01:11 <jclulow> If you're thinking about OI you need to be trimming the repository haha
17:01:37 <hpqoeu> oh right my bad, didn't quite understand
17:01:49 <jclulow> I have 1GB OmniOS VMs that can use pkg just fine though 
17:02:13 <toasterson> Even with trimming the solver code will need more than 4gb soon again
17:02:14 <toasterson> It will need a rewrite of the build process
17:02:31 <toasterson> oh, then we will be ok long, good to know
17:33:01 <rzezeski> went to push a new CR patchset for 1585 (ktest) after it has languished for 18 months and saw the following:
17:33:04 <rzezeski> https://gist.github.com/rzezeski/254c36746d43691b905e4019568f4e2d
17:33:11 <rzezeski> this mean anything to anyone?
17:33:26 <andyf> I think you need to re-base that on a more recent gate
17:33:32 <rzezeski> I did
17:33:45 <rzezeski> sitting atop `e13f92368d64a8efb300e6217cc0931bf766e6d4`
17:35:08 <andyf> When I've seen that error, a re-base has sorted it for me, so this must be something else.
17:36:16 <rzezeski> yea I'm on latest as of Jan 23 2023, is that already too old? :)
17:36:47 <andyf> Maybe it's trying to work out what's changed from the last base, and there's some pruning gone on in gerrit..
17:36:54 <andyf> I'll stop guessing
17:37:05 <rzezeski> yea, it's a pretty ancient CR
17:37:19 <rzezeski> the rebase was fun
17:38:08 <rzezeski> anyways, have other stuff to tend to, I'll try another rebase later and if that doesn't work then I guess it's new CR time
17:38:12 <toasterson> rzezeski: If you rebased before some commit got dropped and thus history is broken
17:38:49 <rzezeski> toasterson: not following, are you saying we mucked with the history in gate?
17:39:25 <toasterson> no, something between CR and gate mucked in you local history
17:45:52 <rzezeski> I pulled out my best Software Engineer hat and googled the error message, stackoverflow gave me the helpful answer of trying `--no-thin` and that did the trick
17:46:06 <rzezeski> don't be like me kids, don't let your projects languish
17:55:26 <toasterson> rzezeski: oh, but then you have --thin somwhere in your git options to spped up pulls?
17:55:59 <rzezeski> not by choice if I do
17:56:05 <rzezeski> I am a minimalist git user
17:56:15 <rzezeski> I don't configure shit but my name and email
17:56:55 <toasterson> did you initially pull that tree with thin? that's not a default option because of things like that
17:57:12 <rzezeski> no, as I said, I am minimalist, I never heard of this until today
17:57:54 <rzezeski> I try to stay out of git man pages as much as possible and just travel down the worn path 
17:59:45 <gogofc> haha I'm just passing by but I like the way you speak "worn path" :)
19:11:34 <richlowe> toasterson: our sources have no platuart or platmmc anymore 
19:16:04 <toasterson> yes, question is if those two drivers are actually one with different device tree configuration
19:18:18 <richlowe> no they aren't.
19:18:23 <richlowe> ones a serial port.
19:20:37 <toasterson> yes but you split platuart up into pl011, ns16550a and mesonuart
19:20:42 <toasterson> as example
19:32:47 <richlowe> because that's 3-ish different uarts
19:33:12 <richlowe> (that's actually open for debate, I'm waiting for some folks at oxide to help there)
19:33:49 <richlowe> but they're not separate because of the device tree.
19:33:57 <richlowe> nor is the mmc
19:39:33 <richlowe> you're probably going to have the same question about virtio.  similar-answer :)
19:41:55 <toasterson> no, virtio makes sense since that is a dedicated driver compared to say intel. But as far as I can tell at least in things like uart and gpio a lot more things are handled in device tree than as seperate drivers.
19:42:16 <toasterson> Linux had a make it generic movement in 2013 when device tree came to arm embedded
19:44:45 <richlowe> the uart stuff could become generic, probably, the mmc stuff couldn't.
19:44:57 <richlowe> or at least, if it did it would be with an abstraction on top, etc, that probably isn't useful.
19:45:49 <toasterson> mmc is probably one of the drivers that has too many differences yes.
19:46:39 <toasterson> My research into the arm device trees shows that it used heavily though to use generic drivers
19:46:50 <richlowe> uart stuff could ideally end up being our existing driver, where it's the same part
19:47:05 <richlowe> but I know oxide are in that area for basically the same reason, so I was waiting to see what they did
19:47:11 <richlowe> because I haven't found time to just go look yet
19:47:33 <richlowe> pull requests accepted!
19:48:06 <toasterson> ah, i am unaware of their movements. In that case it's best to give them time to get some input in
19:56:40 <toasterson> well at least the pl011 ans ns16550 seperation also happened in linux.... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/04293484720403a7860920aaa004cae23aa132a3>)
19:58:57 <toasterson> I have a feeling we are getting a whole lot of drivers :)
20:00:54 <toasterson> Although I see none of the drivers I am looking at right now using device tree
20:04:04 <richlowe> well right, it's just a matter of what they attach to, which is driven out of the nexus enumerating things, which _is_ the device tree
20:05:50 <toasterson> Yep but there was also a lot of talk about providing the source header constants from the device tree
20:15:38 <gitomat> [illumos-gate] 14955 track namespace state in nvme -- Hans Rosenfeld <rosenfeld⊙gho>
20:54:40 <gitomat> [illumos-gate] 15347 bringovercheck and sccscheck can go away -- Bill Sommerfeld <sommerfeld⊙ame>
22:36:34 <richlowe> jperkin: can you share before/after of the GNU strip problem?  I would share them further, if you did.
23:02:03 <andyf> richlowe - without further analysis, https://paste.ec/paste/7p96L3Q5#TEHfcuUTLt4HkV34OLbszIHTahvJ+w3jwsxGjzsYZcU
23:02:35 <andyf> it's something we need to look at in OmniOS too, although we use native tools where possible so gstrip doesn't get used much
23:02:52 <richlowe> I actually just built (just about), though there's a mysterious gdb failure
23:06:09 <andyf> It's at the very least removing the contents of .interp so it remains but is empty
23:06:24 <richlowe> oh yeah, it's causing chaos, and apparently knows it is, given the warning spew.
23:08:41 <andyf> This might be one of those cases to use the funky actuators to force a downgrade.. when I remember how they work
23:14:42 <richlowe> what I don't understand is -- unless I'm just absolutely an idiot -- all its complaints just aren't true.
23:20:05 <jbk> has anyone looked at the gnu strip code?
23:25:27 <andyf> I have started looking through diffs from binutils 2.39, but there is a lot
23:25:51 <richlowe> I see the code, I do not understand the failing of it.
23:27:25 <richlowe> elf.c:7236 looks wrong, and like it should be an && based on the comment.
23:27:34 <richlowe> but we only get there if we think a segment contains no sections
23:29:25 <richlowe> this seems pretty likely to be my fault
23:34:07 <andyf> That particular code hasn't changed since 2.39 though
23:34:09 <richlowe> but apparently in a way 2.39 handled
23:34:21 <richlowe> andyf: right, the thing is it thinks we have no sections in all these segments, etc.
23:35:11 <richlowe> so it finds two segments that are "empty" and N sections that "aren't in segments"
23:40:58 <richlowe> not my fault, but _our_ fault.
23:41:04 <richlowe> I'll try to put something together tomorrow.
23:41:50 <richlowe> at the very least, I now know what's wrong.
23:42:24 <andyf> That's great. The code you mentioned definitely looks wrong but I didn't spot why num_sections is zero now