also.. anyone know if there's any gotchas with bumping the size of the kernel's message buffer?

this panic produced so much output that ::msgbuf lost the beginning of it (I'm thinking because of the # of cpus)

github.com/illumos/illumos-gate/blo…sr/src/uts/i86pc/sys/apix.h#L98-L99 probably harmless, but I feel like that cast is too soon (i.e. mask off the bits, then cast isntead of cast, then mask)

It's been a while but I'm getting back into Zig's support for Illumos. The code for doing stack dumps was rewritten and can unwind via unwind tables or the frame pointer. I'm debating whether to always use fp unwinding on Illumos since it works better than unwind tables.

Are there any Illumos distros that use `-fforce-omit-frame-pointer`? From what I've seen this isn't true.

i don't believe so

just because things like pstack, mdb, and dtrace rely on frame pointers for stack traces (it's less complicated than winding code, so fewer opportunities for errors, and with 64-bit, you can usually spare the register)

is aarch64 support within reach?

toasterking - only for compiling specific artefacts like BIOS ROMs. As jbk said, we value debugging a bit to much otherwise.

rpz recently bumped the version of zig in omnios to 0.15.1 if you wanted/needed a starting point for anything

makr - there is a functional, but still experimental, aarch64 port. I'm using it for a few things on Raspberry Pi 4s though.

thanks andyf

We keep some ready to go images at downloads.omnios.org/media/braich which can be booted under qemu or on a rpi4.

(Where "We" is the OmniOS project)

gitlab.gnome.org/GNOME/glib/-/merge_requests/4887 - I've just assumed this will work on illumos too, not actually tested it

oh great, i got it running, thank you!

/dev/null is a symlink? o_O

lrwxrwxrwx 1 root root 27 Oct 17 2018 /dev/null -> ../devices/pseudo/mm@0:null

ohh interesting

on Solaris, pretty much everything under /dev is a symlink to the actual device in /devices

ah. does the "mm@0" have a meaning?

(with some exceptions, like /dev/fd being a mount point for a special filesystem type)

I'm sure it does, but I don't remember it off hand

mm - memory driver, and it's instance 0. It has minor nodes for the /dev/null, /dev/zero and /dev/full devices.

and /dev/mem, /dev/kmem.. which is presumably the origin of its name

that's neat

more of a dumping ground for miscellaneous pseudo-devices

sommerfeld - I was inferring from "/dev/mem" being first in its list, and it being called the "memory driver". But it's certainly where I'd stick any future similar devices :) - /dev/full was a late addition.

well if nothing else, i've leared more about the low level details on how interrupts work on this...

though all the casting and mixing of signed and unsigned types gives me some heartburn :)

like in some places we pass a uint32_t to a function that's expecting an int, etc.

jbk: the promotion/etc rules make that ok in 99.9% of cases

even worse

rmustacc and less so others have been trying to be very careful about all that

but any code older than that, obviously, is what it is

yeah, i'm pretty sure this is all stuff that hasn't been touched since the sun days

we have several wireless drivers where, I suppose, a code reviewer said "Use fixed size types", and they used `int8_t *` for strings

illumos contains multitudes

just now that i'm trying to piece together how things work

and one thing I wasn't sure of is this system has 2 CPUs (64 cores ea).. the x2apic ids on the 2nd cpu start at 512

which means: x2apic mode and not apic mode should be enabled by the bios normally (seems like that's the case)

but also, you obviously have apic ids > 255

which I wonder might be an issue -- i've not looked at this before, so I don't know if that was something common enough that even on higher core machines was something we've encountered before or not...

there's not too much hw in the system itself -- 2 mellanox cx-6 cards (2 ports ea) and an HPE branded megaraid card, plus the typical built-in bits (USB, iLO)

but the most recent example... apix_pci_msi_enable_vector() -- target_apic_id is int, but is being passed in a uint32_t (and should probably just be a uint32_t)

or that somewhat dubious cast I found yesterday

illumos mentioned! hachyderm.io/@cliffle/115429703942334462

and it was better than the Solaris mention elsewhere in the thread: hachyderm.io/@alanc/115442314555656670

I remember talking about this crap with someone

jclulow you?

illumos 17030 (fenix)?

issue '17030' not found...

I think the infra must be suffering again

Have you heard about this? gx.do is this still alive?

we apparently fixed it when ADI was being triggered on the reads past the end of the allocated buffers

some day, I will free my mind enough to really concentrate on the equivalent arm features

except for TBI, for which my mind may never be free enough

(do we tag .dynamic, and then set the as limits etc on exec? is there more?)

and then maybe, just maybe, you'll get to do it again for x86: osnews.com/story/143601/intel-amd-t…memory-tagging-to-x86-at-some-point

techhub.social/@fosdembsd⊙bc/115442760816869102 talks about illumos at FOSDEM