[illumos-gate] 16510 mdb incorrectly prints the IPv6 Traffic Class -- Bill Sommerfeld <sommerfeld⊙ho>

wiedi_ there is known problem with framebuffer: code.illumos.org/c/illumos-gate/+/1879

→ CODE REVIEW 1879: 14320 loader.efi: Do not use as frame buffer BLT-only GOPs. (NEW) | illumos.org/issues/14320

tsoome: oh cool - I'll give that a spin, thanks!

it should be fairly safe, that patch is quite old

in worst case scenario, we still end up with no framebuffer, but without KMS/DRM drivers we really can not help about it.

I'm currently in Crete, only checking computer time to time:) but I'm back next week.

enjoy your time :)

rmustacc: Robert, do you have plans to add NVMe reservation support to nvmeadm/libnvme ?

there's an existing API for doing SCSI-2 and SCSI-3 style reservations on disks (mhd(4I)).. that'd probably be the preferred way to do it (add support for those ioctls)

jbk do you mind to look on code.illumos.org/c/illumos-gate/+/1746 once again?:)

→ CODE REVIEW 1746: 14151 truss: truss should recognize VMM ioctl codes (NEW) | illumos.org/issues/14151

sure

vetal, jbk: While I owe Hans stuff on namespaces as part of taking on libnvme, I have no plans for multipathing. We don't use it at all and I'm usually suspect of it from the Fishworks days due to CAP. We don't use it, so I have zero plans to work on it.

rmustacc: Thanks, Probably it should be added. I will take a look.

I suspect you want what Jason points out as something that exists on the disk device rather than the controller/namespace. So things like mhd probably want to be the starting point.

I would review an IPD on this and would highly encourage that prior to any work being done.

But also, we need to work out how that can be tested and related by folks without multipathing systems.

I have a lot of libnvme work ahead of me and like 99% of folks with NVMe no multipath (by design).

I do wnat to emphasize, if someone is doing this, please write up an IPD before we get to CR. That will save us a lot of time and back and forth.

rmustacc: I would like to add it into my repo, then check working and then probably discuss.

I would really encourage that we get to a shared design first. If you need to prototype fine, but if this becomes it has to be the way I did it because it's already done and I refused to discus design, I'm going to be disappointed/frustrated.

I've seen enough arguments about design in reviews that I feel very strongly that we should agree on it before CR.

rmustacc: "CAP" as in Brewer's CAP theorem?

rmustacc: you are right, I want to get prototype. Of course it should be discussed before going to upstream.

Thank you neirac for the SO_REUSEPORT email & gerrit, and testing-so-far. I'll have a good look at this on Monday (modulo any disasters).

looks like the new review is code.illumos.org/c/illumos-gate/+/3457

→ CODE REVIEW 3457: 12455 Add SO_REUSEPORT authored-by: araragihokuto⊙oc (NEW) | illumos.org/issues/12455

[illumos-gate] 16528 clean up low-hanging warnings in svccfg(8) -- Richard Lowe <richlowe⊙rn>