Switch to -1

So if I'm reading this correctly, there are a couple of changes here that aren't quite described in the commit log:

In D43239#1108863, @imp wrote:

In D43239#1108862, @jhb wrote:

So the one failure in the exp-run is apparently we have a port that builds the FreeBSD libusb for Linux using /compat/linux/bin/gcc and that version of GCC is too old to support c17.

So do we care? And is it too old to support gnu11? There's no material difference between the two that affects us, right? Could that port not use tgat, assuming upgrading to a newer gcc isn't possible...

FYI, all other arches unconditionally STAILQ_INIT() the list in allocated maps. 32-bit arm initializes the list twice which is somewhat confusing.

Compared to the output from the previous review, the changed lines for devinfo -uv are:

Before in a VM:

Fix looking up root0

Sigh, so yeah, the simple fix is DEVINFO_ROOT_DEVICE should probably be (uintptr_t)-1 or some such instead of NULL. Looks like libdevinfo is used by some ports like libinput and kwin. :( We could always just bump the SHLIB_MAJOR in main to fix this and not worry about fixing stable branches?

In D48501#1110081, @jrtc27 wrote:

That makes sense. The bit that doesn't to me is the portion of the range that's marked as owned by root0. Is that just a quirk of libdevinfo's DEVINFO_ROOT_DEVICE sentinel being 0, which is the same as NULL reports, i.e. for when there's no parent? Seems like that should instead be a different sentinel so NULL device fields can be handled correctly (that or each caller needs to check for NULL).

In D48674#1110075, @imp wrote:

This is a good idea...
Not entirely sure, though, we can hit the KBI stability needed for it.

In D48501#1109394, @jrtc27 wrote:

In D48501#1109382, @jhb wrote:

Booting a RISC-V image under qemu with a virtio-rng-pci device seems to have exercised this as it has a pci_host_generic as a child of a simplebus:

pcib0: <Generic PCI host controller> mem 0x30000000-0x3fffffff on simplebus1
pcib0: parsing FDT for ECAM0:
pcib0: Bus is cache-coherent
pcib0: PCI addr: 0x0, CPU addr: 0x3000000, Size: 0x10000, Type: I/O port
pcib0: PCI addr: 0x40000000, CPU addr: 0x40000000, Size: 0x40000000, Type: memory
pcib0: PCI addr: 0x400000000, CPU addr: 0x400000000, Size: 0x400000000, Type: memory
pci0: <PCI bus> on pcib0
pci0: domain=0, physical bus=0
found-> vendor=0x1b36, dev=0x0008, revid=0x00
        domain=0, bus=0, slot=0, func=0
        class=06-00-00, hdrtype=0x00, mfdev=0
        cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords)
        lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
found-> vendor=0x1af4, dev=0x1005, revid=0x00
        domain=0, bus=0, slot=1, func=0
        class=00-ff-00, hdrtype=0x00, mfdev=0
        cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords)
        lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
        intpin=a, irq=0
        MSI-X supports 2 messages in map 0x14
        map[10]: type I/O Port, range 32, base 0, size  5, port disabled
        map[14]: type Memory, range 32, base 0, size 12, memory disabled
        map[20]: type Prefetchable Memory, range 64, base 0, size 14, memory disabled
virtio_pci0: <VirtIO PCI (legacy) Entropy adapter> irq 16 at device 1.0 on pci0
virtio_pci0: Lazy allocation of 0x20 bytes rid 0x10 type 4 at 0
virtio_pci0: Lazy allocation of 0x1000 bytes rid 0x14 type 3 at 0x40000000
`

Some command output:

root@riscv64:~ # pciconf -lb
hostb0@pci0:0:0:0:      class=0x060000 rev=0x00 hdr=0x00 vendor=0x1b36 device=0x0008 subvendor=0x1af4 subdevice=0x1100
virtio_pci0@pci0:0:1:0: class=0x00ff00 rev=0x00 hdr=0x00 vendor=0x1af4 device=0x1005 subvendor=0x1af4 subdevice=0x0004
    bar   [10] = type I/O Port, range 32, base 0, size 32, enabled
    bar   [14] = type Memory, range 32, base 0x40000000, size 4096, enabled
    bar   [20] = type Prefetchable Memory, range 64, base 0, size 16384, enabled
root@riscv64:~ # devinfo -u
I/O memory addresses:
    0x0-0xfffff (root0)
    0x100000-0x100fff (riscv_syscon0)
    0x101000-0x101fff (goldfish_rtc0)
    0x102000-0x2ffffff (root0)
    0x3000000-0x300ffff (pcib0)
    0x3010000-0xbffffff (root0)
....
pcib0 I/O port window:
    0x0-0x1f (virtio_pci0)
    0x20-0xffff (root0)
....

Not with D44207 though, right? Even absent this change it should show up as I/O memory rather than I/O port, right? Or is that just showing that it's still an I/O port from pcib0 downwards; if so, that's not so relevant because that's not changed, what's relevant is how simplebus0 and above see it?

I would suggest we do something in drm-kmod along the lines of:

Use getnameinfo

Add missing free

Booting a RISC-V image under qemu with a virtio-rng-pci device seems to have exercised this as it has a pci_host_generic as a child of a simplebus:

Restore various error checks

In D48595#1109269, @mav wrote:

In D48595#1109250, @jhb wrote:

I'm not quite sure where to put the nvlist_error calls TBH.

Kind of everywhere where errors are possible, I think. On a quick look it seems nvlist functions just stop working after some first error has happened. So I guess it may produce weird results if errors are not checked the caller. But In particular I've noticed that you removed ability to return errors from few places in parse.y.

Two more that I missed

I'm not quite sure where to put the nvlist_error calls TBH.

Drop unused type arg

So the one failure in the exp-run is apparently we have a port that builds the FreeBSD libusb for Linux using /compat/linux/bin/gcc and that version of GCC is too old to support c17.

I have some WIP to add nvme support to ctld and this series of commits are some cleanups before the meatier changes. To date libiscsiutil has just been a place to reduce code duplication between iscsiutil and ctld. Some bits like the log_* wrapper functions aren't iscsi specific and probably don't belong there but would be duplicated otherwise. :(

In D48537#1107487, @imp wrote:

Though we are deleting this...

Mention zfs

This fulfills the promise made in b218441ac074d9cb9417e284980bf87f79a89585 and is intended to be an MFC candidate.

In D44207#1108078, @jhb wrote:

Actually, can you show me the parent devices of pcib0? I wonder if ACPI was passing these requests up to the arm64 nexus and if it was just treating I/O ports as memory?

In D44207#1108043, @jhb wrote:

In D44207#1107979, @markj wrote:

In D44207#1107878, @jhb wrote:

In D44207#1107391, @markj wrote:

In D44207#1105839, @jhb wrote:

@markj can you test this change on your Ampere box?

It boots fine with this change. Is there anything in particular you'd like to see?

Booting fine is the main thing I wanted to see. Can you also apply D48501 (in the stack) on top of this and make sure it still boots fine?

It still boots without problems, but this system boots using ACPI, I think that patch is a no-op here.

Ah, fair enough.

In D44207#1107979, @markj wrote:

In D44207#1107878, @jhb wrote:

In D44207#1107391, @markj wrote:

In D44207#1105839, @jhb wrote:

@markj can you test this change on your Ampere box?

It boots fine with this change. Is there anything in particular you'd like to see?

Booting fine is the main thing I wanted to see. Can you also apply D48501 (in the stack) on top of this and make sure it still boots fine?

It still boots without problems, but this system boots using ACPI, I think that patch is a no-op here.

In D44207#1107391, @markj wrote:

In D44207#1105839, @jhb wrote:

@markj can you test this change on your Ampere box?

It boots fine with this change. Is there anything in particular you'd like to see?

In D48541#1107539, @emaste wrote:

ObsoleteFiles entry too?