On Sun, Aug 16, 2026 at 12:25:56AM -0600, Warner Losh wrote: > On Sat, Aug 15, 2026 at 7:06 PM Konstantin Belousov <[email protected]> > wrote: > > > On Sat, Aug 15, 2026 at 07:36:42AM -0600, Warner Losh wrote: > > > On Sat, Aug 15, 2026 at 2:11 AM Daniel Engberg <[email protected]> > > wrote: > > > > > > > On 2026-08-06 10:50, Daniel Wagner wrote: > > > > > Hi, > > > > > > > > > > I'm maintaining nvme-cli and working on the next major version > > release, > > > > > 3.0. The original plan was just to clean up and refactor the library > > > > > APIs, which included introducing a transport abstraction layer to > > make > > > > > the nvme-cli project portable. This was done primarily to support the > > > > > Management Interface specification (out-of-band communication with an > > > > > NVMe controller) as a first-class citizen rather than a bolt-on > > addition > > > > > to the existing library interface. > > > > > > > > > > And immediately Windows port happened... I was trying to > > counterbalance > > > > > this by figuring out how difficult it would be to natively support > > > > > FreeBSD. I've fixed all the build issues I found and created a dummy > > > > > implementation. > > > > > > > > > > I don't have the time to fully implement the missing pieces, so I'm > > > > > asking here (sorry if this is the wrong place) if anyone wants to > > help > > > > > get it over the line? > > > > > > > > > > https://github.com/linux-nvme/nvme-cli/pull/3745 > > > > > > > > > > Cheers, > > > > > Daniel > > > > Hi Warner, > > > > > > > > Can you have a look at this? > > > > > > > > > > While it is not yet complete, this work is a step in the right direction. > > > Sounds like we > > > both don't have the time to do this on a committed schedule. I am on > > > vacation this > > > week, but I left comments to point in the right direction. It would be at > > > least a month > > > before I'd be able to get back to looking at this. It doesn't look super > > > hard, though, > > > and maybe my comments can get it up at least to the level the current > > > FreeBSD > > > nvme-cli port (at 2.11) is at, if not a bit more. > > > > > > What timeline is 3.0 shaping up to be? > > > > > > > Someone noted the https://github.com/bsdimp/freebsd-nvme-shim to me, > > and I have to reply there with the https://github.com/kostikbel/rdma-core > > branch freebsd. In particular, I mean the freebsd-headers subdirectory. > > > > I'll have to take a closer look when I'm not on vacation... > > > > I think eventually we might want something like linuxAPI (like linuxKPI) > > for userspace compat where we put stuff that is not appropriate for the > > FreeBSD base but is still useful to compile userspace with too many > > linuxisms/glibcisms. > > > > Yes. I toyed with the idea of creating a /usr/include/linux-uapi directory > that > would allow for us to have a uapi-compliant API, at least one "good enough" > for porting those things that have causal linuxisms (where standard-ish APIs > exist, but force of habit keeps people using the linux-APIs out of > ignorance), > but worried about what to do about the more complex things. Like whether > we'd also need a liblinux-uapi or not... Eventually yes, I think. If taken seriously, linuxapi would require a library.
> > So I'm receptive to the idea of moving this into base. Bits of the nvme-shim > are kinda nvme-cli specific (though maybe with its new porting layer api > some of those can go away -- I've no thad time to deal with it). I did not proposed anything like linuxAPI for base. I think that it is not appropriate for base, and should live in ports (similar to e.g. epoll-shim).
