Re: Adding native FreeBSD support to nvme-cli?

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