Re: Adding native FreeBSD support to nvme-cli?

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

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

Warner