would cxgbe be a good example of using firmware files?

ddi_ufm is the way, I believe

I'm not sure how you choose among the drivers using it

I'd guess that and nvme are the most heavily used

i don't think that is for reading a (volatile, not NVM) file to write to the device during attach or such

i guess technically it'd be more of an opaque blob

for E810 (ice) it apparently requires what intel calls a 'dynamic device personalization (DDP)' file that is loaded from the OS during 'initialization' (i.e. attach)... on fbsd, this is apparently done as a separate module (ice_ddp), but based on the readme with it, it seems like the file is redistributable, so instead of trying to wrap it in a module or convert it to a giant .h file, i thoguht there's a way

to read it from the filesystem

(apparently the DDP is required for things like RSS)

and the card enters a 'safe mode' without it

(it seems like most of the other bits in it wouldn't be as useful at this time)

(this is also unlike i40e where the card apparently includes a default configuration in it's NVM)

jbk: Assuming this is a file that basically needs to be read and installed in the hw every boot then yeah, the firmload(9F) bits are what I'd use. The cxgbe examples are fine.

ok

src.illumos.org does return 502 Bad Gateway

Will iscsi served from zfs volume, ever be able to come close to the speed of iscs served from the file (also on zfs) ?

zvol io is sync mode, file io is async. Therefore you either add slog device or switch to use async io... async is obviously coming with price tag.

yeah sync=disabled on zfs volume should help but not much?

comstar?

see wcd property of stmfadm modify-lu (stmfadm list-lu -v)

rmustacc: have you already done the ps(1) mandoc conversion?

[illumos-gate] 17781 swprintf(3c) does not work properly -- Hans Rosenfeld <rosenfeld⊙gho>

jbk: Yes, I have. There's a bug / cr on it.

oh ok...

→ CODE REVIEW 4724: 18085 convert ps(1) to mdoc (NEW) | illumos.org/issues/18085

i had done it for illumos-joyent way back, but never had a chance to create a version for upstream since there's differences between the two manpages

Well, it is what it is.

which i guess is also something for danmcd to be aware of whenever it's merged that they'll have to do some additional work

since the smartos ps has changes not in illumos-gate

Merge hell I can deal with. :)

in this case though it would require doing some additional conversions

Sometimes it's best to reconstruct the diffs from the upstream new one. ps(1) might be one of those times.

We're going to have the same challenge in omnios - our ps(1) man page is differently, er, different.

We really should get that reconciled and upstream something

Does OmniOS have the same diffs SmartOS does? (probably zone-related)?

i believe the difference is the smartos ps shows full cmdline args

or can show it

vs. the truncated upstraem

err upstream

ah, the old 80 char limit..

jbk that's right, but omnios took a different approach than smartos

omnios has `-F` to show up to 4096 characters from the current argv, which may have changed. By default it still shows the original argv like gate does.

It's been a while since I looked, but I believe smartos shows the 4096 version by default (and may actually have -F to do the opposite of omnios)

on an unrelated note, anyone know offhand of an easy way to tell if a USB device is >= 3.0 from it's dip?

(it looks like illumos#14371 might be an issue with some BMCs)

illumos#14371 fenix?

BUG 14371: usb auto-wakeup should support USB 3.0 devices (New)

↳ illumos.org/issues/14371

[illumos-gate] 18044 Extend posix_spawn testsuite coverage -- Andy Fiddaman <illumos⊙fn>

andyf: nice

'twas a good way to learn more about posix_spawn in general :)

I know maybe there are compatibility feelings? But I could absolutely live with `::stack -t` being the default

it'd be neat to mix it up so we could `<N>::argv` and have it ::print appropriately

(I know `argv` is a bad name)