00:19:51 would cxgbe be a good example of using firmware files? 00:21:20 ddi_ufm is the way, I believe 00:22:38 I'm not sure how you choose among the drivers using it 00:23:06 I'd guess that and nvme are the most heavily used 00:25:33 i don't think that is for reading a (volatile, not NVM) file to write to the device during attach or such 00:26:05 i guess technically it'd be more of an opaque blob 00:34:01 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 00:34:07 to read it from the filesystem 00:34:11 (apparently the DDP is required for things like RSS) 00:34:37 and the card enters a 'safe mode' without it 00:35:07 (it seems like most of the other bits in it wouldn't be as useful at this time) 00:36:01 (this is also unlike i40e where the card apparently includes a default configuration in it's NVM) 00:49:34 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. 00:49:46 ok 11:41:01 src.illumos.org does return 502 Bad Gateway 13:12:19 Will iscsi served from zfs volume, ever be able to come close to the speed of iscs served from the file (also on zfs) ? 13:20:20 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. 13:23:26 yeah sync=disabled on zfs volume should help but not much? 13:27:15 comstar? 13:30:47 see wcd property of stmfadm modify-lu (stmfadm list-lu -v) 13:55:55 rmustacc: have you already done the ps(1) mandoc conversion? 15:53:01 [illumos-gate] 17781 swprintf(3c) does not work properly -- Hans Rosenfeld 15:53:29 jbk: Yes, I have. There's a bug / cr on it. 15:53:48 oh ok... 15:54:17 https://code.illumos.org/c/illumos-gate/+/4724 15:54:18 → CODE REVIEW 4724: 18085 convert ps(1) to mdoc (NEW) | https://www.illumos.org/issues/18085 15:54:39 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 15:55:16 Well, it is what it is. 15:55:36 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 15:56:23 since the smartos ps has changes not in illumos-gate 16:03:05 Merge hell I can deal with. :) 17:09:20 in this case though it would require doing some additional conversions 18:13:47 Sometimes it's best to reconstruct the diffs from the upstream new one. ps(1) might be one of those times. 18:14:10 We're going to have the same challenge in omnios - our ps(1) man page is differently, er, different. 18:14:34 We really should get that reconciled and upstream something 18:26:43 Does OmniOS have the same diffs SmartOS does? (probably zone-related)? 18:27:34 i believe the difference is the smartos ps shows full cmdline args 18:27:52 or can show it 18:27:59 vs. the truncated upstraem 18:28:01 err upstream 18:43:08 ah, the old 80 char limit.. 18:46:16 jbk that's right, but omnios took a different approach than smartos 18:47:20 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. 18:48:28 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) 19:02:20 on an unrelated note, anyone know offhand of an easy way to tell if a USB device is >= 3.0 from it's dip? 19:11:02 (it looks like illumos#14371 might be an issue with some BMCs) 19:23:33 illumos#14371 fenix? 19:23:34 BUG 14371: usb auto-wakeup should support USB 3.0 devices (New) 19:23:34 ↳ https://www.illumos.org/issues/14371 19:58:36 [illumos-gate] 18044 Extend posix_spawn testsuite coverage -- Andy Fiddaman 20:05:06 andyf: nice 20:44:23 'twas a good way to learn more about posix_spawn in general :) 21:06:41 I know maybe there are compatibility feelings? But I could absolutely live with `::stack -t` being the default 21:09:16 it'd be neat to mix it up so we could `::argv` and have it ::print appropriately 21:09:29 (I know `argv` is a bad name)