nvme defintions not used in the kernel

nvme defintions not used in the kernel

[Christoph Hellwig]

Hi all,

currently nvme-cli supports various nvme features that are not
needed in the kernel and keeps them in its own nvme.h file,
in addition to pulling in the kernel one.

Do we want to keep it that way in the long run, or just add
things to nvme.h in the kernel even if they are not used to
keep things in a single place.

To me the latter would seem a little nicer, especially as it
doesn't involve a whole lot of defintion.

nvme defintions not used in the kernel

[Jens Axboe]

On 06/28/2017 05:11 PM, Christoph Hellwig wrote:
> Hi all,
> 
> currently nvme-cli supports various nvme features that are not
> needed in the kernel and keeps them in its own nvme.h file,
> in addition to pulling in the kernel one.
> 
> Do we want to keep it that way in the long run, or just add
> things to nvme.h in the kernel even if they are not used to
> keep things in a single place.
> 
> To me the latter would seem a little nicer, especially as it
> doesn't involve a whole lot of defintion.

I'd vote for the latter as well. It's nice for documentation as
well, often easier than grabbing the spec if you are in the driver
anyway.

-- 
Jens Axboe

nvme defintions not used in the kernel

[Sagi Grimberg]

> Hi all,
> 
> currently nvme-cli supports various nvme features that are not
> needed in the kernel and keeps them in its own nvme.h file,
> in addition to pulling in the kernel one.
> 
> Do we want to keep it that way in the long run, or just add
> things to nvme.h in the kernel even if they are not used to
> keep things in a single place.
> 
> To me the latter would seem a little nicer, especially as it
> doesn't involve a whole lot of defintion.

I agree with the latter, should we also move nvme.h to
uapi?

nvme defintions not used in the kernel

[Johannes Thumshirn]

On Thu, Jun 29, 2017@08:44:04AM +0300, Sagi Grimberg wrote:
> I agree with the latter, should we also move nvme.h to
> uapi?

That was my first reaction as well. I'm all for it.

-- 
Johannes Thumshirn                                          Storage
jthumshirn at suse.de                                +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

nvme defintions not used in the kernel

[Christoph Hellwig]

On Thu, Jun 29, 2017@10:32:28AM +0200, Johannes Thumshirn wrote:
> On Thu, Jun 29, 2017@08:44:04AM +0300, Sagi Grimberg wrote:
> > I agree with the latter, should we also move nvme.h to
> > uapi?
> 
> That was my first reaction as well. I'm all for it.

Absolutely not.  It's not a userspace API/ABI.  It's an internal header
that we want to be able to refactor if needed, e.g. if NVMe splits or
renames fields, or adds unions, etc.  It just happens that nvme-cli
needs the same defintions.

nvme defintions not used in the kernel

[Sagi Grimberg]

> Absolutely not.  It's not a userspace API/ABI.  It's an internal header
> that we want to be able to refactor if needed, e.g. if NVMe splits or
> renames fields, or adds unions, etc.  It just happens that nvme-cli
> needs the same defintions.

Yea, lets NOT do that :)

nvme defintions not used in the kernel

[Keith Busch]

On Thu, Jun 29, 2017@01:11:29AM +0200, Christoph Hellwig wrote:
> Hi all,
> 
> currently nvme-cli supports various nvme features that are not
> needed in the kernel and keeps them in its own nvme.h file,
> in addition to pulling in the kernel one.
> 
> Do we want to keep it that way in the long run, or just add
> things to nvme.h in the kernel even if they are not used to
> keep things in a single place.
> 
> To me the latter would seem a little nicer, especially as it
> doesn't involve a whole lot of defintion.

Hm, the only thing nvme-cli should be copying from Linux is the headers
defining ioctls and their arguments. The specification defined structures
and commands should be OS agnostic in the tooling, so personally I think
it's less work to let them evolve independently.

That said, it's a nice goal to keep them in sync if someone wants to
put the effort into that.