how does illumos work on other architectures? I heard that there are still a few binaries that are still closed source, and I was wondering what the future of illumos looks like.

there's a few that are probably not often used (pax) or specific to x86

or sparc

I'm going to pretend I know what that means and say "cool"

pax is like at&t (I think) decided to rewrite 'tar' (sort of)

so no one really uses it

oh I see. sounds completely useless for 99% of all users.

there are other pax implementations

I just installed OpenIndiana for the first time :D Wish me luck on my journey to set it up so that you don't see me again for mundane reasons

I thought pax was invented by the POSIX committee to settle all the arguments between the different tar & cpio implementations

insert xkcd.com/927 here

glad to see everyone loves xkcd as much as I do

alanc: that's what I thought too

[illumos-gate] 15633 libsocket: getallifaddrs() can die with NULL pointer dereference -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 15604 gprof: clean up warning gags -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 15491 libipadm: the comparison will always evaluate as 'true' -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 15607 pvs: clean up warning gags -- Toomas Soome <tsoome⊙mc>

is it just me, or is gerrit currently broken?

error: remote unpack failed: error Missing tree 59fb78569e94f0b5ae4bd384b9194549eb82e5a4

Woodstock: i wonder if that's related to the out of sync thing from yesterday

Woodstock - I've been getting that for weeks, and others have reported it too

the workaround is..

add `--no-thin` to the end of your command line

thanks

Hey @Woodstock -- have you looked at code.illumos.org/c/illumos-gate/+/2716 aka fenix illumos#15483 ?

→ CODE REVIEW 2716: 15483 remove circular from ndi_devi_enter et al (NEW) | illumos.org/issues/15483

I'm curious about your newly-filed fenix illumos#15638 and if one influences the other (or hopefully not).

BUG 15638: panic in scsi_hba_ioctl() (New)

↳ illumos.org/issues/15638 | code.illumos.org/c/illumos-gate/+/2841

danmcd: i checked this and they are unrelated

YES! THANK YOU!

It looks like the previous issue 15463 (fenix) added the assertion that exposed this bug though, which is a nice result.

BUG 15463: ndi_devi_enter et al can be safer and clearer (Closed)

↳ illumos.org/issues/15463 | code.illumos.org/c/illumos-gate/+/2699

[illumos-gate] 15314 bhyve state restore should be safe -- Patrick Mooney <pmooney⊙pc>

[illumos-gate] 15483 remove circular from ndi_devi_enter et al -- Dan Cross <cross⊙oc>

andyf/Woodstock: doing a "git fetch" on the Gerrit remote prior to the push may also avoid/work around the "missing tree" error.

.oO ../../intel/os/archdep.c:186:1: error: 'fxsave_to_fpregset' defined but not used and ../../intel/os/archdep.c:173:1: error: 'fpregset_to_fxsave' defined but not used

Not surprising given the refactoring and the lack of warning.

Those used to be called by getfpregs(), which was repalced to a single call to fpu.c driven code.

can be removed, I take it

tsoome: better dead code detection in newer gcc?

that one was with clang-15

but I haven't set the same gags on clang as we have for gcc

gcc would do it fine if we told it too.

-Wunused-function is nuanced with respect to debug builds historically.

yep.

At least it's not the double-edged sword of -Wunused-argument.

This commit made that function unused: illumos/illumos-gate ed093b4

what would be the recommended flags for ctfconvert/ctfmerge for building a third-party kernel module?

Nothing too special I think - I would not try and uniquify against genunix for example.

I'm just building fuse on omnios to see what it does

for tran_init_pkt() -- almost every invocation seems to pass NULL for arg1 (scsi_pkt) -- I'm assuming if actually non-NULL, the HBA should still just set all of the fields just as if it had called scsi_hba_pkt_alloc() and received a new scsi_pkt, right?

It does `ctfconvert -i -L VERSION fuse_vfsops.o` on every object then merges it all together at the end with

`ctfmerge -L VERSION -o fuse fuse_dev.o fuse_ini.o fuse_queue.o fuse_vnops.o fuse_vfsops.o`

but you can also do a convert on the final linked object nowadays

I would do exactly what our makefiles do, honestly.

Some do a converstion on the final linked object nowadays :D

with `CTF_MODE=link`

right, I meant the other flags etc.

we use the undocumented -X

which I guess deals with some struct cpu mess

Right, I think that's necessary (or at least helpful) if you are genunix, or are not uniquified against something that is genunix.

(it's probably unlikely that fuse cares about the machcpu though)

but all I have heard of fuse is bad things

one of these days, I'd still like to look at the work from long ago (I saved a branch) which used doors under the covers

for fuse

it's not really the implementation people have complained about in my presence

It was just the first out-of-gate kernel module I found.

Here's a probably better one github.com/omniosorg/illumos-kvm/blob/master/Makefile#L302-L313

andyf: i have added outside builds like fuse to original dilos-illumos build through external repo injections to be built with correct CTF

andyf: i did it for tun/tap, fuse, etc builds

andyf: because debug was painful if you have no types in genunix

hmm.. do any of the mdb API sym functions understand module`sym?

mdb_readsym() at least does not appear to

i should probably go ahead and throw up my changes for c11 anonymous struct and unions for ctf (I had done some bits for mdb, but moving it to ctf should allow it to also work for other things)... if I can find it :)

even if we don't use them in-gate, we can still leverage ctf for anything that does

on smartos, especially, that's a lot of stuff.

(the same is true of omnios, but omnios is smaller)