On 11/10/2015 3:27 PM, Dan Williams wrote:
On Tue, Nov 10, 2015 at 11:49 AM, Jerry Hoemann <jerry.hoemann@xxxxxxx> wrote:
On Tue, Nov 10, 2015 at 12:51:59PM -0500, Jeff Moyer wrote:
Jerry Hoemann <jerry.hoemann@xxxxxxx> writes:
Add IOCTL type 'P' to denote NVDIMM_TYPE_PASSTHRU.
Can't you just make passthrough a separate command? If you actually add
There are multiple conflicting NVDIMM _DSM running around, they
are "device specific". So, we should plan in general and not just
for the example DSM that Intel added support for. These DSM have
over lapping and incompatible function ids.
The Intel example is an example, not standard. They are free to
change it at will. So, we can't be certain there won't be a
conflict some time in the future if we try to use their number space.
I'm trying to create a generic pass thru that any vendors can use. Putting
this in the Intel function number space doesn't make a lot of sense to me.
It isn't the "Intel" function number space. The fact that they
currently align is just a happy accident.
It's not really a happy accident. Your commit message says it
was derived from the Intel spec 'for convenience', which I think is convenient
for anything that implements that spec.
We've discussed ways of supporting different command sets with you
and determined that this pass-through mechanism was a good approach
because it allows multiple different command sets to be support in
a generic way. Blending the two flavors (generic pass through and explicit
function definitions) is confusing to me.
The kernel is free to break
the 1:1 ioctl number to DSM function number relationship, and I think
it would make the implementation cleaner in this case.
To me it's less clean and even for your own example spec, less
convenient if Intel ever updates that spec.
-- ljk
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@xxxxxxxxxxxx
https://lists.01.org/mailman/listinfo/linux-nvdimm
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
