Re: [PATCH v2 0/3] nvdimm: Add an IOCTL pass thru for DSM calls

From: Jerry Hoemann
Date: Wed Nov 18 2015 - 02:01:42 EST

On Tue, Nov 17, 2015 at 09:05:28AM -0800, Dan Williams wrote:
> On Tue, Nov 17, 2015 at 8:56 AM, Jerry Hoemann <jerry.hoemann@xxxxxxx> wrote:
> > On Mon, Nov 16, 2015 at 05:29:41PM -0800, Dan Williams wrote:
> >> On Mon, Nov 16, 2015 at 1:10 PM, Jerry Hoemann <jerry.hoemann@xxxxxxx> wrote:
> >> > On Mon, Nov 16, 2015 at 11:00:20AM -0800, Dan Williams wrote:
> >> >> On Mon, Nov 16, 2015 at 10:38 AM, Jerry Hoemann <jerry.hoemann@xxxxxxx> wrote:
> >> >> >
> >> >>
> >
> > ...
> >
> >> I want to do it in separate steps, I'd just like to see cmd number 100
> >> added to the existing __nd_ioctl and acpi_nfit_ctl routines. That
> >
> > Why?
> Because there's no need for the intel vs passthru distinction, it's
> just yet another command.

Yes and no. The way the two marshal their arguments in prep for
the copy in/copy out is different and are not compatible.

Also, the existing upstream acpi_nfit_ctl does multiple things that
we don't want done in the "semi" passthru case.

To accomodate these differences, I implemented in separate functions.
I can merge the functions together, it will not be clean.

This approach also creates testing issues I didn't have previously. I
was confident w/ code inspection that I wasn't breaking the existing
usage case. I will need your help in testing on hardware that I don't
have access to.

You expressed a desire to depricate the existing ioctl commands
and transition to the semi passthru structure.

What do you anticipate that code looking like?

> >> plus quibbling about the name "ND_CMD_PASSTHRU". Given the plans to
> >> eventually replace the existing commands we can call it something like
> >
> >
> > No problem. I'll change the name for ndn_passthru_pkg in a similar fashion.
> >
> >
> > Question: Are you planning to add other CMDs to the IOCTL in the future?
> > (eg. ones not directly related to calling _dsm?)
> >
> > Or, is the ultimate goal to have an IOCTL that supports
> > only the generic DSM call?
> I'm not ruling out the possibility that there may be a non-DSM command
> in the future, but I don't see any need for that on the horizon. Why
> would it matter?

Neither the existing upstream apci_nfit_ctl nor the semi pass thru
marshal arguments in a traditional straight forward manner. So likely
the marshaling code for any new commands would be different.

Also, since it doesn't call DSM it wouldn't be doing the evaluate dsm.


Jerry Hoemann Software Engineer Hewlett-Packard Enterprise
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at