.oO Nov 1 10:18:37 beastie pcie: [ID 324549 kern.warning] WARNING: pci_pci-1: encountered PCIe device without PCIe capability

-1?

seems -1 yes

Another one? Seems they are not as uncommon as suspected.

That's issue 15056 (fenix)

BUG 15056: Missing pcie cap leads to panic in pcie_fabric_feature_scan() (Closed)

↳ illumos.org/issues/15056 | code.illumos.org/c/illumos-gate/+/2450

[illumos-gate] 14568 bhyve should support pause/resume -- Patrick Mooney <pmooney⊙pc>

There seems to be a history of (at least an attempt) at high quality C for illumos, have there been interesting bugs that have made it past lint?

I've been actually learning Rust, even though I went through the Rust Book years ago

I'm sure we have lot of bugs still in hidden

clang is exposing them atm...

Is illumos building with llvm?

not yet

I have cleaned handful of libraries and few other bits from build system

_lots_ of bugs make it past lint

How many bugs are higher level than the programming language constraints? Do you think they would manifest if written in Rust?

rust or similar would have saved me personally from lots of annoyance

except for having to write all the rust-y stuff in support

not much use using rust if all your access to system facilities is directly via unsafe and C

someone needs to step up and write the good rusty abstractions for ... everything

I think there's still a lot of value in new code being safe even if most of the things it initially depends upon are not safe

I think I just said what I meant poorly

if the new code you write is, indeed, not largely `unsafe' in the rust-y sense, then yeah

I would look very favourably on anyone who knew how making the effort, definitely

I don't know how, but I've convinced myself I can figure anything out as long as it doesn't make me motion sick.

^tongue in cheek

I have forgotten what availdevs(1? 8?) does, but if someone (jbk? yurip?) wanted to rewrite it to not, for reasons I can't even begin to fathom, use the JNI libzfs directly from C, rather than libzfs, I'd be grateful .

yuripv: I know you like deleting things, think of it is letting you maybe delete libzfs_jni one day :)

whaaaaaaat

what fresh hell is this

who even uses this

just usr/src/tools/quick/make-zfs as far as I can see

it core dumps on my system too (availdevs)

ha

my guess is maybe it was tsol?

or something

oh good lord tools/quick

that's gordon wanting to gordon

good grief why are the getopts characters in the header

:)

I cannot find anything in GitHub or a cursory glance at Google that runs /usr/lib/zfs/availdevs

It's not in PATH, and it sucks: I think we should delete it

neither could I, it came it with ZFS

I assume it is either for an installer (but not caiman?) or the ZFS appliance

But probably the appliance did something else anyway

→ BUG 15147: remove /usr/lib/zfs/availdevs (New)

Hey @jbk ==> you're on the short list for code-reviewers for illumos.org/issues/15146

→ BUG 15146: sadb_unlinkassoc() isn't idempotent (New)

ok i looked

For the record, I'm not the _only_ person who has found the $SRC/tools/quick scripts useful.

Under a minute or so edit/compile/debug cycle.

I thought with them in the gate more people would use them. If you find them offensive, just delete them and those of us who use them can just keep them somewhere else.

I was just explaining their provinence!

the only thing I want to set on fire right now is availdevs

It's in the ZFS packaging, and the quick build tried to build everything in that package... (though that was probably not necessary)

the packaging is... less good than even I thought it was

though I think ZFS is less bad about it

The other problem with the quick stuff is that the tools builds (particularly building make) takes 5X as long as the rest of the "quick" build, unless you use "bldenv +t" or something.

I'm not sure why the tools rebuild so often. The intent of that stuff is that a rebuild should build _only_ what you need to deliver.

(and do it quickly)

I think under nightly it might be because we have to build them separately and swap them out, and that screws up with KEEP_STATE

a plain clean build in usr/src/tools rebuilds nothing (for me), and re-installs minimal stuff (cw)

oh, cw and install.bin not just cw

so I don't know if it's the nightly thing, or something at racktop

wow, just found a comment string for gosling emacs

all over lp, and of course, one in ksh93

does anyone have a broadwell-era intel machine running illumos?

can you give that in model or family or something? I'm bad at names

(it would be a nice feature for psrinfo to print them.)

it'd be a v4 suffix for the xeon models

v2 = ivy bridge, v3 = haswell, v4 = broadwell

IIUC

(I'm trying to figure out when intel added hardware access/dirty page tracking to EPT)

my ivy bridge machine lacks it

gwr: It's fine, I just have no idea how we're testing them to ensure they actually work

I did!

> wow, just found a comment string for gosling emacs

like...James Gosling?

yeah, the emacs clone he wrote in the early 80s

has anyone looked at libressl making a bunch of openssl internals we use (eugh) actually private and invisible?

I had no idea we did such apparently nasty things to openssl

I'm going through the list of stuff I don't build right now, and that's among the scarier ones, maintenance-wise

TIL