linux-kernel - Re: [PATCH 2/4] nvdimm: Add IOCTL pass thru

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 11 Nov 2015 10:41:37 -0500
From:	Jeff Moyer <jmoyer@...hat.com>
To:	Jerry.Hoemann@....com
Cc:	ross.zwisler@...ux.intel.com, rjw@...ysocki.net, lenb@...nel.org,
	dan.j.williams@...el.com, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-nvdimm@...1.01.org
Subject: Re: [PATCH 2/4] nvdimm: Add IOCTL pass thru

Jerry Hoemann <jerry.hoemann@....com> writes:

> On Tue, Nov 10, 2015 at 01:05:20PM -0500, Jeff Moyer wrote:
>> Jerry Hoemann <jerry.hoemann@....com> writes:
>> 
>> > Add internal data structure for ndctl_passthru call.
>> >
>> > Signed-off-by: Jerry Hoemann <jerry.hoemann@....com>
>> > ---
>> >  include/linux/libnvdimm.h | 1 +
>> >  1 file changed, 1 insertion(+)
>> >
>> > diff --git a/include/linux/libnvdimm.h b/include/linux/libnvdimm.h
>> > index 3f021dc..01117e1 100644
>> > --- a/include/linux/libnvdimm.h
>> > +++ b/include/linux/libnvdimm.h
>> > @@ -72,6 +72,7 @@ struct nvdimm_bus_descriptor {
>> >  	unsigned long dsm_mask;
>> >  	char *provider_name;
>> >  	ndctl_fn ndctl;
>> > +	ndctl_fn ndctl_passthru;
>> 
>> I don't think this is necessary.  Vector off inside of __nd_ioctl.  That
>> especially makes sense if you do switch to passthrough as a command
>> instead of a type, but it can work either way.
>> 
>
> In an earlier version, I added a "type" argument to ndctl_fn and switched
> internally based upon that.  I just came to the conclusion that I'd rather
> have two separate acpi_nfit_ctl functions than one trying to do both sets
> of argument marshaling.  This is quite different both internally and
> to the caller.
>
> So, I thought it would be less confusing to the next engineer, and that
> this was a good logical separation point.

I'll leave this up to Dan.  To me, it doesn't make sense to add a new
ioctl function for every new type of ioctl that get's added (assuming
more types will follow).

Cheers,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/