12:16 a.m.
On Mon, Apr 11, 2016 at 11:21:45AM -0700, Dan Williams wrote:
On Mon, Mar 21, 2016 at 12:37 PM, Jerry Hoemann
<jerry.hoemann(a)hpe.com> 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....
--
-----------------------------------------------------------------------------
Jerry Hoemann Software Engineer Hewlett Packard Enterprise
-----------------------------------------------------------------------------