Re: Adding native FreeBSD support to nvme-cli?

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).