From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g9t5008.houston.hp.com (g9t5008.houston.hp.com [15.240.92.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id D107A1A1EE5 for ; Mon, 11 Apr 2016 17:19:39 -0700 (PDT) Date: Mon, 11 Apr 2016 18:19:37 -0600 From: Jerry Hoemann Subject: Re: [PATCH v8 02/10] nvdimm: Add wrapper for IOCTL pass thru Message-ID: <20160412001937.GE119165@tevye.fc.hp.com> References: <20160411231657.GB119165@tevye.fc.hp.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Jerry.Hoemann@hpe.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Dan Williams Cc: "linux-nvdimm@lists.01.org" List-ID: On Mon, Apr 11, 2016 at 04:23:55PM -0700, Dan Williams wrote: > On Mon, Apr 11, 2016 at 4:16 PM, Jerry Hoemann wrote: > > On Mon, Apr 11, 2016 at 11:21:45AM -0700, Dan Williams wrote: > >> On Mon, Mar 21, 2016 at 12:37 PM, Jerry Hoemann wrote: > >> > + > >> > +/* > >> > + * the list nd_family of commands. The mapping to firmware handles > >> > + * is definied in the nfit_cmd_family_tbl > >> > + * > >> > + */ > >> > +#define ND_TYPE_BUS 1 > >> > +#define ND_TYPE_DIMM_INTEL1 2 > >> > +#define ND_TYPE_DIMM_N_HPE1 3 > >> > +#define ND_TYPE_DIMM_N_HPE2 4 > >> > + > >> > + > >> > +#define ND_IOCTL_CALL _IOWR(ND_IOCTL, ND_CMD_CALL,\ > >> > + struct nd_cmd_pkg) > >> > + > >> > + > >> > + > >> > #endif /* __NDCTL_H__ */ > >> > >> Looks, good, but for now lets assume there will never be such a thing > >> as ND_TYPE_BUS commands or an ND_CMD_CALL for the bus. I.e. all the > >> commands that currently exist for the bus are commands that the kernel > >> wants to handle. In this way, struct nd_cmd_pkg is a solution to the > >> problem of commands that the kernel knows exist, but has no use case > >> to generate or parse itself. Commands that fit that description > >> currently only exist in leaf node implementations. > > > > > > Would user space application ever want to call commands for the bus? > > > > I assume the answer is yes, as there are ioctls for ND_CMD_ARS_CAP, etc., > > > > My thoughts here was to make the pass thru uniform, capable of calling > > all the dsm functions that a user space agent might want to call. I.e > > don't make user call some _DSM functions one way, and other DSM function > > another way.... > > > > Indeed that would have been nice had that been the implementation from > the beginning, but binaries using the current more verbose interface > are already shipping in distributions. So, the train has already left This doesn't break existing binaries. They will still work. I'm looking at the world going forward. :) > the station on having a "one ioctl interface to rule them all" > interface. > > Unless the ACPI working group adds a slew of kernel irrelevant > commands to the bus, I don't see nd_cmd_pkg being needed at that root > device level. -- ----------------------------------------------------------------------------- Jerry Hoemann Software Engineer Hewlett Packard Enterprise ----------------------------------------------------------------------------- _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm