From Newsgroup: muc.lists.freebsd.ports
--0000000000000798730659242183
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Sat, Aug 15, 2026 at 7:06=E2=80=AFPM Konstantin Belousov <kostikbel@gmai= l.com>
wrote:
On Sat, Aug 15, 2026 at 07:36:42AM -0600, Warner Losh wrote:
On Sat, Aug 15, 2026 at 2:11=E2=80=AFAM Daniel Engberg <diizzy@freebsd.=
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 librar=
y
APIs, which included introducing a transport abstraction layer to
make
the nvme-cli project portable. This was done primarily to support t=
he
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 dumm=
y
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 directio=
n.
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 supe=
r
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 API=
s
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-shi=
m
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
--0000000000000798730659242183
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g= mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Aug 15,=
2026 at 7:06=E2=80=AFPM Konstantin Belousov <<a href=3D"mailto:kostikbe=
l@gmail.com">
kostikbel@gmail.com</a>> wrote:<br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex">On Sat, Aug 15, 2026 at 07:36:42AM -0600, = Warner Losh wrote:<br>
> On Sat, Aug 15, 2026 at 2:11=E2=80=AFAM Daniel Engberg <<a href=3D"= mailto:
diizzy@freebsd.org" target=3D"_blank">
diizzy@freebsd.org</a>> wro= te:<br>
> <br>
> > On 2026-08-06 10:50, Daniel Wagner wrote:<br>
> > > Hi,<br>
> > ><br>
> > > I'm maintaining nvme-cli and working on the next major v= ersion release,<br>
> > > 3.0. The original plan was just to clean up and refactor the=
library<br>
> > > APIs, which included introducing a transport abstraction lay=
er to make<br>
> > > the nvme-cli project portable. This was done primarily to su= pport the<br>
> > > Management Interface specification (out-of-band communicatio=
n with an<br>
> > > NVMe controller) as a first-class citizen rather than a bolt= -on addition<br>
> > > to the existing library interface.<br>
> > ><br>
> > > And immediately Windows port happened... I was trying to cou= nterbalance<br>
> > > this by figuring out how difficult it would be to natively s= upport<br>
> > > FreeBSD. I've fixed all the build issues I found and cre= ated a dummy<br>
> > > implementation.<br>
> > ><br>
> > > I don't have the time to fully implement the missing pie= ces, so I'm<br>
> > > asking here (sorry if this is the wrong place) if anyone wan=
ts to help<br>
> > > get it over the line?<br>
> > ><br>
> > > <a href=3D"
https://github.com/linux-nvme/nvme-cli/pull/3745"=
rel=3D"noreferrer" target=3D"_blank">
https://github.com/linux-nvme/nvme-cl= i/pull/3745</a><br>
> > ><br>
> > > Cheers,<br>
> > > Daniel<br>
> > Hi Warner,<br>
> ><br>
> > Can you have a look at this?<br>
> ><br>
> <br>
> While it is not yet complete, this work is a step in the right directi= on.<br>
> Sounds like we<br>
> both don't have the time to do this on a committed schedule. I am = on<br>
> vacation this<br>
> week, but I left comments to point in the right direction. It would be=
at<br>
> least a month<br>
> before I'd be able to get back to looking at this. It doesn't = look super<br>
> hard, though,<br>
> and maybe=C2=A0 my comments can get it up at least to the level the cu= rrent<br>
> FreeBSD<br>
> nvme-cli port (at 2.11) is at, if not a bit more.<br>
> <br>
> What timeline is 3.0 shaping up to be?<br>
> <br>
Someone noted the <a href=3D"
https://github.com/bsdimp/freebsd-nvme-shim" r= el=3D"noreferrer" target=3D"_blank">
https://github.com/bsdimp/freebsd-nvme-= shim</a> to me,<br>
and I have to reply there with the <a href=3D"
https://github.com/kostikbel/= rdma-core" rel=3D"noreferrer" target=3D"_blank">
https://github.com/kostikbe= l/rdma-core</a><br>
branch freebsd.=C2=A0 In particular, I mean the freebsd-headers subdirector= y.<br></blockquote><div><br></div><div>I'll have to take a closer look = when I'm not on vacation...=C2=A0</div><div>=C2=A0</div><blockquote cla= ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid = rgb(204,204,204);padding-left:1ex">
I think eventually we might want something like linuxAPI (like linuxKPI)<br=
for userspace compat where we put stuff that is not appropriate for the<br> FreeBSD base but is still useful to compile userspace with too many<br> linuxisms/glibcisms.<br></blockquote><div><br></div><div>Yes. I toyed with = the idea of creating a /usr/include/linux-uapi directory that</div><div>wou=
ld allow for us to have a uapi-compliant API, at least one "good enoug= h"</div><div>for porting those things that have causal linuxisms (wher=
e standard-ish APIs</div><div><span style=3D"background-color:transparent">= exist, but force of habit keeps people using the linux-APIs out of ignoranc= e),</span></div><div><span style=3D"background-color:transparent">but worri=
ed about what to do about the more complex things. Like whether</span></div= ><div><span style=3D"background-color:transparent">we'd also need a lib= linux-uapi or not...</span></div><div><span style=3D"background-color:trans= parent"><br></span></div><div><span style=3D"background-color:transparent">=
So I'm receptive to the idea of moving this into base. Bits of the nvme= -shim</span></div><div><span style=3D"background-color:transparent">are kin=
da nvme-cli specific (though maybe with its new porting layer api</span></d= iv><div><span style=3D"background-color:transparent">some of those can go a= way -- I've no thad time to deal with it).</span></div><div><span style= =3D"background-color:transparent"><br></span></div><div><span style=3D"back= ground-color:transparent">Warner</span></div></div></div>
--0000000000000798730659242183--
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to
news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2