[illumos-gate] 17919 MAC softring (set) status and types should be enums and documented -- Kyle Simpson <kyle⊙oc>

Wow, this is sounds great: github.com/LuminousMonkey/xf86-video-illumosfb

Provides an unaccelerated framebuffer driver for running a 2D X11 desktop on illumos systems where no native GPU driver exists (e.g. Nvidia Blackwell, recent AMD, Intel Arc). Works with any system that exposes a UEFI GOP framebuffer via /dev/fb0 through the kernel's gfxp_bitmap driver.

hrm.. not a huge deal, but all of that pointer indirection and feature detection might be able to be replaced with linker capabilities...

unfortunately, they're not well known, but are kinda neat

(basically you can provide different implementations of the same function using different CPU features, and the linker will pick the 'best' one)

i'm handwaving a bit, but that's the basic idea

symbol caps in the kernel would require krtld support

(so would object caps, but I'm going to assume nobody wants those)

it's an x86 driver through, not a kernel driver

so userland

so presumably if it's built as an .so, it'd work...

granted, I'm not sure how challenging it'd be to build it with autoconf

oh I somehow thought you were looking at the network performance stuff out of oxide

no i was talking about the xf86-video-illumosfb driver

i took a look and it's using a function pointer to pick an optimized 'copy' routine based on avx support

at least it's not STT_GNU_IFUNC

which see, if you have the stomach

:o

is that the gcc 'dispatch a function based on cpu capabilities' bit?

jbk: that's the GNU "bind a function based on the runtime linker calling a user-function that chooses"

it's "more general"

oh yeah

rmustacc: should github.com/illumos/illumos-gate/blo…pc/io/pci/pci_prd_i86pc.c#L797-L811 be using pci_prd_upcalls->pru_bus2dip_f() there (or any reason not to do that you can think of?)