nvme defintions not used in the kernel
Christoph Hellwig
maintainerHi 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.
Quoted 6 lines · 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.hfile, in addition to pulling in the kernel one.
Quoted 6 lines
Do we want to keep it that way in the long run, or just add things to
nvme.hin 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.
Signature · 1 line
Jens Axboe
Sagi Grimberg
maintainerQuoted 6 lines
Hi all,
currently nvme-cli supports various nvme features that are not needed in the kernel and keeps them in its own
nvme.hfile, in addition to pulling in the kernel one.
Quoted 6 lines
Do we want to keep it that way in the long run, or just add things to
nvme.hin 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?
Quoted 2 lines · Sagi Grimberg
I agree with the latter, should we also move
nvme.hto uapi?
That was my first reaction as well. I'm all for it.
Signature · 6 lines
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
Christoph Hellwig
maintainerQuoted 5 lines · Johannes Thumshirn
Quoted 2 lines · Sagi Grimberg
I agree with the latter, should we also move
nvme.hto 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.
Sagi Grimberg
maintainerQuoted 4 lines
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 :)
Quoted 6 lines · 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.hfile, in addition to pulling in the kernel one.
Quoted 6 lines
Do we want to keep it that way in the long run, or just add things to
nvme.hin 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.