tsoome are you working with a loader build that has wiki.freebsd.org/FlattenedDeviceTree enabled?

Is there a roadmap for Illumos?

Also, is the name ill-um-os or il-lum-os? Both?

it comes from illuminati, as a pun to Sun.. so it's illum-os most likely.

Then there are illum-putians?

Taht would be a giant step on the roadmap

Would it be to challenging to ask if a multi-arch concept for Illumos was considered?

**too

what do you mean with multi-arch

There used to be SPARC but I think that was dropped quite recently?

Seems to be a x86 only structure - or have I guessed wrong. I could go look at the open source.

people are working on ARM

But that's like reading the manual.

and yeah, there was SPARC until very recently

There still are SPARC distributions of illumos

Well, Sparc went without mentioning... are there working Sparc boards? not many, I suspect

IPD #36 looks interesting. Any action on relegating 32 bits to the heap of history?

I prefer 12 bit computing platforms, usually.

If you have not debugged 12 bit machine code from a 16 bit Sun, you haven't been anywhere.

Luser0: We have x86 some SPARC and are working on ARMv8 and Risc-V as platforms.

Who makes a Risc-V?

A Japanese fellow made a port

we are in the works of integrating it together with the ARM port

I meant the hardware. Is it still produced?

RISC-V is extremely new

it's more that hardware is not widely available yet than any sort of "still"

It's mostly a University piece and has a loyal Open source followship

I sorry ... don't let the Finnish know I spouted.

but you can buy RISC-V hardware from e.g. sifive.com

That's why they'd rather have South Americans banning me from IRC than let that whale float, down here, where we all float.

Too bad I wasn't a financial whale. But I am putting on pounds... I may qualify soon. Just call me Jabba!

New ice cream flavor. Jabba the Hutt, just add RiscV sprinkles.

The Admiral has been dead awhile, anyway. Huh!.

toasterson: where are the most up to date ARM/RISC-V ports?

thats inluding cross build toolchain and image builder for qemu

I am also working on github.com/solarm-project

thanks!

Where I'm gona place my things and distribution work.

Still want to push OI but I will need to redo the buildsystem anyways so I am making it in a language I understand

and you can boot a mini ARM omnios today, with downloads.omnios.org/media/braich

Know who does the = Vector data stride L2 prefetcher unit

omnios has begun their integrations aswell, so they will eventually have builds from their tree aswell

andyf: ha, you also went with braich :)

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

yeah I figured you where blazing towards that end. Which is why I am working myself down to the hardware level ATM

Think that ECX Fabric will ever run on a Windos platform?

Must be why the new chief was selected from the specific chosen.

Blazing is generous, especially compared to how much work richlowe is putting in. I need to make time to pick up some more there.

And Stefan Raab has some relationship to Illumos?

stefan raab of pro7? :-)

Sure, the German news anchor. Not

The cloudfront guy with Braich. Is Braich still changing coordinates?

Braich is derived from the Latin Braccium for Arm :) It's a pun

in Welsh and Irish

No, it's the guy who made us miss Bin Laden and kill his wife and kids, instead.

But he probably doesn't put that on his business card.

He should have taken the poison that Kowala got.

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): kebe.com/~danmcd/webrevs/14892/dp_pcache_poll-14892.patch

BUG 14892: pollhead lifetime too short in signalfd (In Progress)

↳ illumos.org/issues/14892

danmcd: I was hoping to swing back to that function and do some restructuring, rather than sprinkling releasefd() throughout

it's already hard enough to read as-is

Fair point.

that function is already at or beyond the breaking point when it comes to complexity

But that patch should cover the cases where php was being used/manipulated AFTER releasef(). It could inform a refactoring.

yeah, I'm aware of what needs to be done

it's a matter of working up the gumption to do it

and deciding what path to take

Oh thank goodness for debug kernels... :)

It tripped on the devpoll dp_pcache_poll() (though why it GPF'ed with an allocated buffer is beyond me).

which did

your patch or the "vanilla" 14892 one?

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

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).

I tripped it with the simple repro program running 8 times concurrently plus a shell script looping through pkills.

Luckily both devpoll and signalfd are standalone modules, making experimentation/replacement easy.

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

rpi 4 4gb ram 16gb emmc

no wireless

or qemu

bhyve?

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

It should probably work in 2GB of RAM also right

no bhyve, we use the emulator of qemu

jclulow: currently without IPS yes

oh so no vms basically? or at least not hardware accelerated i guess

IPS should be able to work in 2GB of RAM

it's a differnt ISA hpqoeu so hypervisor support is a new driver

jclulow: well... experience tells no. I am happy to be proven wrong though

helios might with the current amount of packages

If you're thinking about OI you need to be trimming the repository haha

oh right my bad, didn't quite understand

I have 1GB OmniOS VMs that can use pkg just fine though

Even with trimming the solver code will need more than 4gb soon again

It will need a rewrite of the build process

oh, then we will be ok long, good to know

went to push a new CR patchset for 1585 (ktest) after it has languished for 18 months and saw the following:

this mean anything to anyone?

I think you need to re-base that on a more recent gate

I did

sitting atop `e13f92368d64a8efb300e6217cc0931bf766e6d4`

When I've seen that error, a re-base has sorted it for me, so this must be something else.

yea I'm on latest as of Jan 23 2023, is that already too old? :)

Maybe it's trying to work out what's changed from the last base, and there's some pruning gone on in gerrit..

I'll stop guessing

yea, it's a pretty ancient CR

the rebase was fun

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

rzezeski: If you rebased before some commit got dropped and thus history is broken

toasterson: not following, are you saying we mucked with the history in gate?

no, something between CR and gate mucked in you local history

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

don't be like me kids, don't let your projects languish

rzezeski: oh, but then you have --thin somwhere in your git options to spped up pulls?

not by choice if I do

I am a minimalist git user

I don't configure shit but my name and email

did you initially pull that tree with thin? that's not a default option because of things like that

no, as I said, I am minimalist, I never heard of this until today

I try to stay out of git man pages as much as possible and just travel down the worn path

haha I'm just passing by but I like the way you speak "worn path" :)

toasterson: our sources have no platuart or platmmc anymore

yes, question is if those two drivers are actually one with different device tree configuration

no they aren't.

ones a serial port.

yes but you split platuart up into pl011, ns16550a and mesonuart

as example

because that's 3-ish different uarts

(that's actually open for debate, I'm waiting for some folks at oxide to help there)

but they're not separate because of the device tree.

nor is the mmc

you're probably going to have the same question about virtio. similar-answer :)

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.

Linux had a make it generic movement in 2013 when device tree came to arm embedded

the uart stuff could become generic, probably, the mmc stuff couldn't.

or at least, if it did it would be with an abstraction on top, etc, that probably isn't useful.

mmc is probably one of the drivers that has too many differences yes.

My research into the arm device trees shows that it used heavily though to use generic drivers

uart stuff could ideally end up being our existing driver, where it's the same part

but I know oxide are in that area for basically the same reason, so I was waiting to see what they did

because I haven't found time to just go look yet

pull requests accepted!

ah, i am unaware of their movements. In that case it's best to give them time to get some input in

well at least the pl011 ans ns16550 seperation also happened in linux.... (full message at <libera.ems.host/_matrix/media/v3/do…484720403a7860920aaa004cae23aa132a3>)

I have a feeling we are getting a whole lot of drivers :)

Although I see none of the drivers I am looking at right now using device tree

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

Yep but there was also a lot of talk about providing the source header constants from the device tree

[illumos-gate] 14955 track namespace state in nvme -- Hans Rosenfeld <rosenfeld⊙gho>

[illumos-gate] 15347 bringovercheck and sccscheck can go away -- Bill Sommerfeld <sommerfeld⊙ame>

jperkin: can you share before/after of the GNU strip problem? I would share them further, if you did.

richlowe - without further analysis, paste.ec/paste/7p96L3Q5#TEHfcuUTLt4HkV34OLbszIHTahvJ+w3jwsxGjzsYZcU

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

I actually just built (just about), though there's a mysterious gdb failure

It's at the very least removing the contents of .interp so it remains but is empty

oh yeah, it's causing chaos, and apparently knows it is, given the warning spew.

This might be one of those cases to use the funky actuators to force a downgrade.. when I remember how they work

what I don't understand is -- unless I'm just absolutely an idiot -- all its complaints just aren't true.

has anyone looked at the gnu strip code?

I have started looking through diffs from binutils 2.39, but there is a lot

I see the code, I do not understand the failing of it.

elf.c:7236 looks wrong, and like it should be an && based on the comment.

but we only get there if we think a segment contains no sections

this seems pretty likely to be my fault

That particular code hasn't changed since 2.39 though

but apparently in a way 2.39 handled

andyf: right, the thing is it thinks we have no sections in all these segments, etc.

so it finds two segments that are "empty" and N sections that "aren't in segments"

not my fault, but _our_ fault.

I'll try to put something together tomorrow.

at the very least, I now know what's wrong.

That's great. The code you mentioned definitely looks wrong but I didn't spot why num_sections is zero now