nvdimm: Add an IOCTL pass thru for DSM calls

PATCH Superseded Jerry Hoemann 2 participants 10 messages Nov 16, 2015 – Nov 18, 2015

Subsystems (2)

ACPI libnvdimm: non-volatile memory device

lore

Share & tools

lore

Jerry Hoemann

author

2015-11-16 18:38 UTC #0 lore raw

v2 cover nvdimm: Add an IOCTL pass thru for DSM calls

The NVDIMM code in the kernel supports an IOCTL interface to user space based upon the Intel Example DSM:

http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf

This interface cannot be used by other NVDIMM DSMs that support incompatible functions.

This patch set adds a generic "passthru" IOCTL interface which is not tied to a particular DSM.

A new _IOC_NR ND_CMD_PASSTHRU == "100" is added for the pass thru call.

The new data structure nd_passthru_pkg serves as a wrapper for the passthru calls. This wrapper supplies the data that the kernel needs to make the _DSM call.

Unlike the definitions of the _DSM functions themselves, the nd_passthru_pkg provides the calling information (input/output sizes) in an uniform manner making the kernel marshaling of the arguments straight forward.

This shifts the marshaling burden from the kernel to the user space application while still permitting the kernel to internally call _DSM functions.

To make the resultant kernel code easier to understand the existing functions acpi_nfit_ctl and __nd_ioctl were renamed to .*_intel to denote calling mechanism as in 4.3 tailored to the Intel Example DSM. New functions acpi_nfit_ctl_passthru and __nd_ioctl_passthru were created to supply the pass thru interface.

These changes are based upon the 4.3 kernel.

Changes in version 2:
---------------------
1. Cleanup access mode check in nd_ioctl and nvdimm_ioctl.
2. Change name of ndn_pkg to nd_passthru_pkg
3. Adjust sizes in nd_passthru_pkg. DSM intergers are 64 bit.
4. No new ioctl type, instead tunnel into the existing number space.
5. Push down one function level where determine ioctl cmd type.
6. re-work diagnostic print/dump message in pass-thru functions.

Jerry Hoemann (3):
nvdimm: Clean-up access mode check.
nvdimm: Add wrapper for IOCTL pass thru
nvdimm: Add IOCTL pass thru functions

 drivers/acpi/nfit.c        |  93 ++++++++++++++++++++++++++++++++++++++++-
 drivers/nvdimm/bus.c       | 101 +++++++++++++++++++++++++++++++++++++++++----
 include/uapi/linux/ndctl.h |  16 +++++++
 3 files changed, 202 insertions(+), 8 deletions(-)

Signature · 1 line

1.7.11.3

Jerry Hoemann

author

2015-11-16 18:38 UTC #1 lore raw

PATCH v2 1/3 nvdimm: Clean-up access mode check.

Change nd_ioctl and nvdimm_ioctl access mode check to use O_RDONLY.

Signed-off-by Jerry Hoemann <[email protected]>

---
 drivers/nvdimm/bus.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

drivers/nvdimm/bus.c +6 -6

index 7e2c43f..1c81203 100644
@@ -602,14 +602,14 @@ static int __nd_ioctl(struct nvdimm_bus *nvdimm_bus, struct nvdimm *nvdimm,
 static long nd_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 {
 	long id = (long) file->private_data;
-	int rc = -ENXIO, read_only;
+	int rc = -ENXIO, ro;
 	struct nvdimm_bus *nvdimm_bus;
 
-	read_only = (O_RDWR != (file->f_flags & O_ACCMODE));
+	ro = ((file->f_flags & O_ACCMODE) == O_RDONLY);
 	mutex_lock(&nvdimm_bus_list_mutex);
 	list_for_each_entry(nvdimm_bus, &nvdimm_bus_list, list) {
 		if (nvdimm_bus->id == id) {
-			rc = __nd_ioctl(nvdimm_bus, NULL, read_only, cmd, arg);
+			rc = __nd_ioctl(nvdimm_bus, NULL, ro, cmd, arg);
 			break;
 		}
 	}

@@ -633,10 +633,10 @@ static int match_dimm(struct device *dev, void *data)
 
 static long nvdimm_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 {
-	int rc = -ENXIO, read_only;
+	int rc = -ENXIO, ro;
 	struct nvdimm_bus *nvdimm_bus;
 
-	read_only = (O_RDWR != (file->f_flags & O_ACCMODE));
+	ro = ((file->f_flags & O_ACCMODE) == O_RDONLY);
 	mutex_lock(&nvdimm_bus_list_mutex);
 	list_for_each_entry(nvdimm_bus, &nvdimm_bus_list, list) {
 		struct device *dev = device_find_child(&nvdimm_bus->dev,

@@ -647,7 +647,7 @@ static long nvdimm_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 			continue;
 
 		nvdimm = to_nvdimm(dev);
-		rc = __nd_ioctl(nvdimm_bus, nvdimm, read_only, cmd, arg);
+		rc = __nd_ioctl(nvdimm_bus, nvdimm, ro, cmd, arg);
 		put_device(dev);
 		break;
 	}

Signature · 1 line

1.7.11.3

Jerry Hoemann

author

2015-11-16 18:38 UTC #2 lore raw

PATCH v2 2/3 nvdimm: Add wrapper for IOCTL pass thru

In reply to Jerry Hoemann

Add struct nd_passthru_pkg which serves as a warapper for the data being passed via a pass thru to a NVDIMM DSM. This wrapper specifies the extra information in a uniform manner allowing the kenrel to call a DSM without knowing specifics of the DSM.

Signed-off-by Jerry Hoemann <[email protected]>

---
 include/uapi/linux/ndctl.h | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

include/uapi/linux/ndctl.h +16 -0

index 5b4a4be..934a49f 100644
@@ -109,6 +109,7 @@ enum {
 	ND_CMD_VENDOR_EFFECT_LOG_SIZE = 7,
 	ND_CMD_VENDOR_EFFECT_LOG = 8,
 	ND_CMD_VENDOR = 9,
+	ND_CMD_PASSTHRU = 100,
 };
 
 enum {

@@ -204,4 +205,19 @@ enum ars_masks {
 	ARS_STATUS_MASK = 0x0000FFFF,
 	ARS_EXT_STATUS_SHIFT = 16,
 };
+
+
+struct nd_passthru_pkg {
+	struct {
+		__u8	dsm_uuid[16];
+		__u64	dsm_rev;		/* revision of dsm call  */
+		__u64	dsm_fun_idx;		/* DSM function id       */
+		__u32	dsm_in;			/* size of _DSM input    */
+		__u32	dsm_out;		/* size of user buffer   */
+		__u64	reserved[12];		/* reserved must be zero */
+		__u32	dsm_size;		/* size _DSM would write */
+	} h;
+	unsigned char buf[];
+};
+
 #endif /* __NDCTL_H__ */

Signature · 1 line

1.7.11.3

Jerry Hoemann

author

2015-11-16 18:38 UTC #3 lore raw

PATCH v2 3/3 nvdimm: Add IOCTL pass thru functions

In reply to Jerry Hoemann

Add functions acpi_nfit_ctl_passthru and __nd_ioctl_passthru which allow kernel to call a nvdimm's _DSM as a passthru without the marshaling code of the nd_cmd_desc.

Signed-off-by Jerry Hoemann <[email protected]>

---
 drivers/acpi/nfit.c  | 93 +++++++++++++++++++++++++++++++++++++++++++++++++++-
 drivers/nvdimm/bus.c | 89 ++++++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 180 insertions(+), 2 deletions(-)

drivers/acpi/nfit.c +92 -1

index c1b8d03..88844af 100644
@@ -62,7 +62,7 @@ static struct acpi_device *to_acpi_dev(struct acpi_nfit_desc *acpi_desc)
 	return to_acpi_device(acpi_desc->dev);
 }
 
-static int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc,
+static int acpi_nfit_ctl_intel(struct nvdimm_bus_descriptor *nd_desc,
 		struct nvdimm *nvdimm, unsigned int cmd, void *buf,
 		unsigned int buf_len)
 {

@@ -190,6 +190,97 @@ static int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc,
 	return rc;
 }
 
+
+static int acpi_nfit_ctl_passthru(struct nvdimm_bus_descriptor *nd_desc,
+		struct nvdimm *nvdimm, unsigned int cmd, void *buf,
+		unsigned int buf_len)
+{
+	struct acpi_nfit_desc *acpi_desc = to_acpi_nfit_desc(nd_desc);
+	union acpi_object in_obj, in_buf, *out_obj;
+	struct device *dev = acpi_desc->dev;
+	const char *dimm_name;
+	acpi_handle handle;
+	const u8 *uuid;
+	int rc = 0;
+	__u64 rev = 0, func = 0;
+
+	struct nd_passthru_pkg *pkg = buf;
+
+	if (nvdimm) {
+		struct nfit_mem *nfit_mem = nvdimm_provider_data(nvdimm);
+		struct acpi_device *adev = nfit_mem->adev;
+
+		if (!adev)
+			return -ENOTTY;
+		dimm_name = nvdimm_name(nvdimm);
+		handle = adev->handle;
+	} else {
+		struct acpi_device *adev = to_acpi_dev(acpi_desc);
+
+		handle = adev->handle;
+		dimm_name = "bus";
+	}
+	uuid = pkg->h.dsm_uuid;
+	rev  = pkg->h.dsm_rev;
+	func = pkg->h.dsm_fun_idx;
+
+	in_obj.type = ACPI_TYPE_PACKAGE;
+	in_obj.package.count = 1;
+	in_obj.package.elements = &in_buf;
+	in_buf.type = ACPI_TYPE_BUFFER;
+	in_buf.buffer.pointer = (void *) &pkg->buf;
+
+	in_buf.buffer.length = pkg->h.dsm_in;
+
+	if (IS_ENABLED(CONFIG_ACPI_NFIT_DEBUG))
+		print_hex_dump_debug("nvdimm in  ", DUMP_PREFIX_OFFSET, 4, 4,
+			in_buf.buffer.pointer,
+			min_t(u32, 256, in_buf.buffer.length), true);
+
+	out_obj = acpi_evaluate_dsm(handle, uuid, rev, func, &in_obj);
+	if (!out_obj) {
+		dev_dbg(dev, "%s:%s _DSM failed idx: %llu\n", __func__,
+				dimm_name, func);
+		return -EINVAL;
+	}
+
+	if (out_obj->package.type != ACPI_TYPE_BUFFER) {
+		dev_dbg(dev, "%s:%s unexpected object type: %d type: %d\n",
+				__func__, dimm_name, cmd, out_obj->type);
+		rc = -EINVAL;
+		goto out;
+	}
+
+	if (IS_ENABLED(CONFIG_ACPI_NFIT_DEBUG))
+		print_hex_dump_debug("nvdimm out ", DUMP_PREFIX_OFFSET, 4, 4,
+			out_obj->buffer.pointer,
+			min_t(u32, 256, out_obj->buffer.length), true);
+
+	pkg->h.dsm_size = out_obj->buffer.length;
+	memcpy(pkg->buf + pkg->h.dsm_in,
+			out_obj->buffer.pointer,
+			min(pkg->h.dsm_size, pkg->h.dsm_out));
+
+
+ out:
+	ACPI_FREE(out_obj);
+
+	return rc;
+}
+
+static int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc,
+		struct nvdimm *nvdimm, unsigned int cmd, void *buf,
+		unsigned int len)
+{
+	switch (cmd) {
+	case ND_CMD_PASSTHRU:
+		return acpi_nfit_ctl_passthru(nd_desc, nvdimm, cmd, buf, len);
+	default:
+		return acpi_nfit_ctl_intel(nd_desc, nvdimm, cmd, buf, len);
+	}
+}
+
+
 static const char *spa_type_name(u16 type)
 {
 	static const char *to_name[] = {

drivers/nvdimm/bus.c +88 -1

101 lines not on this page · raw message

Signature · 1 line

1.7.11.3

Dan Williams

2015-11-16 19:00 UTC #4 lore raw

In reply to Jerry Hoemann

Quoted 27 lines · Jerry Hoemann

The NVDIMM code in the kernel supports an IOCTL interface to user space based upon the Intel Example DSM:
http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
This interface cannot be used by other NVDIMM DSMs that support incompatible functions.
This patch set adds a generic "passthru" IOCTL interface which is not tied to a particular DSM.
A new _IOC_NR ND_CMD_PASSTHRU == "100" is added for the pass thru call.
The new data structure nd_passthru_pkg serves as a wrapper for the passthru calls. This wrapper supplies the data that the kernel needs to make the _DSM call.
Unlike the definitions of the _DSM functions themselves, the nd_passthru_pkg provides the calling information (input/output sizes) in an uniform manner making the kernel marshaling of the arguments straight forward.
This shifts the marshaling burden from the kernel to the user space application while still permitting the kernel to internally call _DSM functions.

Quoted 5 lines

To make the resultant kernel code easier to understand the existing functions acpi_nfit_ctl and __nd_ioctl were renamed to .*_intel to denote calling mechanism as in 4.3 tailored to the Intel Example DSM. New functions acpi_nfit_ctl_passthru and __nd_ioctl_passthru were created to supply the pass thru interface.

Let's not do the _intel vs _passthru split. I want to convert the existing commands over to this new interface and deprecate the old ioctl-command formats. I.e. it isn't the case that this will be a always be a blind "passthru" mechanism, the kernel will need to crack open this payload in some circumstances.

Jerry Hoemann

author

2015-11-16 21:10 UTC #5 lore raw

Quoted 34 lines · Dan Williams

Quoted 27 lines · Jerry Hoemann
The NVDIMM code in the kernel supports an IOCTL interface to user space based upon the Intel Example DSM:
http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
This interface cannot be used by other NVDIMM DSMs that support incompatible functions.
This patch set adds a generic "passthru" IOCTL interface which is not tied to a particular DSM.
A new _IOC_NR ND_CMD_PASSTHRU == "100" is added for the pass thru call.
The new data structure nd_passthru_pkg serves as a wrapper for the passthru calls. This wrapper supplies the data that the kernel needs to make the _DSM call.
Unlike the definitions of the _DSM functions themselves, the nd_passthru_pkg provides the calling information (input/output sizes) in an uniform manner making the kernel marshaling of the arguments straight forward.
This shifts the marshaling burden from the kernel to the user space application while still permitting the kernel to internally call _DSM functions.
Quoted 5 lines
To make the resultant kernel code easier to understand the existing functions acpi_nfit_ctl and __nd_ioctl were renamed to .*_intel to denote calling mechanism as in 4.3 tailored to the Intel Example DSM. New functions acpi_nfit_ctl_passthru and __nd_ioctl_passthru were created to supply the pass thru interface.

Quoted 5 lines

Let's not do the _intel vs _passthru split. I want to convert the existing commands over to this new interface and deprecate the old ioctl-command formats. I.e. it isn't the case that this will be a always be a blind "passthru" mechanism, the kernel will need to crack open this payload in some circumstances.

I'm confused.

In this version there is only 1 ioctl 'N'. The pass thru is using number 100. This is what I thought you wanted from prior comments.

The split are for internal functions that deal specifically w/ the argument marshaling code and copy-in/copy-out. These mechanisms are different.

I understand that you want to switch over, but don't you (at least for the time being) need to keep the old marshaling code for the current
use case? I was assuming a sequence like:
1. The pass thru code gets submitted.
2. The current tools are converted over to using the pass thru,
3. The marshaling code using nd_cmd_in_size etc., would then be removed.

Are you wanting to make one big change and not in separate steps?

Now I don't currently have provision for "snooping" out specific functions in the pass thru flow. The 4.3 code doesn't do that either per se. It will do the calls asked of it from the user.

Snooping is a feature that could be added, but since I'm not sure your plans here, the best I can do at the moment is to put in a hook to a function that is a no-op. The meat of this function to be added when plans become more firm. Do you have more specific info here?

Signature · 3 lines

-----------------------------------------------------------------------------
Jerry Hoemann            Software Engineer      Hewlett-Packard Enterprise
-----------------------------------------------------------------------------

Dan Williams

2015-11-17 01:29 UTC #6 lore raw

Quoted 42 lines · Jerry Hoemann

Quoted 34 lines · Dan Williams
Quoted 27 lines · Jerry Hoemann
The NVDIMM code in the kernel supports an IOCTL interface to user space based upon the Intel Example DSM:
http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
This interface cannot be used by other NVDIMM DSMs that support incompatible functions.
This patch set adds a generic "passthru" IOCTL interface which is not tied to a particular DSM.
A new _IOC_NR ND_CMD_PASSTHRU == "100" is added for the pass thru call.
The new data structure nd_passthru_pkg serves as a wrapper for the passthru calls. This wrapper supplies the data that the kernel needs to make the _DSM call.
Unlike the definitions of the _DSM functions themselves, the nd_passthru_pkg provides the calling information (input/output sizes) in an uniform manner making the kernel marshaling of the arguments straight forward.
This shifts the marshaling burden from the kernel to the user space application while still permitting the kernel to internally call _DSM functions.
Quoted 5 lines
To make the resultant kernel code easier to understand the existing functions acpi_nfit_ctl and __nd_ioctl were renamed to .*_intel to denote calling mechanism as in 4.3 tailored to the Intel Example DSM. New functions acpi_nfit_ctl_passthru and __nd_ioctl_passthru were created to supply the pass thru interface.
Quoted 5 lines
Let's not do the _intel vs _passthru split. I want to convert the existing commands over to this new interface and deprecate the old ioctl-command formats. I.e. it isn't the case that this will be a always be a blind "passthru" mechanism, the kernel will need to crack open this payload in some circumstances.

Quoted 4 lines

I'm confused.
In this version there is only 1 ioctl 'N'. The pass thru is using number 100. This is what I thought you wanted from prior comments.

It is indeed, I like that change.

Quoted 12 lines

The split are for internal functions that deal specifically w/ the argument marshaling code and copy-in/copy-out. These mechanisms are different.
I understand that you want to switch over, but don't you (at least for the time being) need to keep the old marshaling code for the current
use case? I was assuming a sequence like:
1. The pass thru code gets submitted.
2. The current tools are converted over to using the pass thru,
3. The marshaling code using nd_cmd_in_size etc., would then be removed.

Quoted 1 line

Are you wanting to make one big change and not in separate steps?

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 plus quibbling about the name "ND_CMD_PASSTHRU". Given the plans to eventually replace the existing commands we can call it something like 'ND_DSM_GENERIC'.

Quoted 8 lines

Now I don't currently have provision for "snooping" out specific functions in the pass thru flow. The 4.3 code doesn't do that either per se. It will do the calls asked of it from the user.
Snooping is a feature that could be added, but since I'm not sure your plans here, the best I can do at the moment is to put in a hook to a function that is a no-op. The meat of this function to be added when plans become more firm. Do you have more specific info here?

No need to add the snooping support now, I only made the comment in reference to the "passthru" name. We can add snooping support later after we finalize this initial marshaling code.

Jerry Hoemann

author

2015-11-17 16:56 UTC #7 lore raw

Quoted 5 lines · Dan Williams

Quoted 4 lines · Jerry Hoemann
Quoted 3 lines · Dan Williams
Quoted 1 line · Jerry Hoemann

...

Quoted 26 lines

Quoted 11 lines
Quoted 5 lines
Let's not do the _intel vs _passthru split. I want to convert the existing commands over to this new interface and deprecate the old ioctl-command formats. I.e. it isn't the case that this will be a always be a blind "passthru" mechanism, the kernel will need to crack open this payload in some circumstances.
I'm confused.
In this version there is only 1 ioctl 'N'. The pass thru is using number 100. This is what I thought you wanted from prior comments.
It is indeed, I like that change.
Quoted 12 lines
The split are for internal functions that deal specifically w/ the argument marshaling code and copy-in/copy-out. These mechanisms are different.
I understand that you want to switch over, but don't you (at least for the time being) need to keep the old marshaling code for the current
use case? I was assuming a sequence like:
1. The pass thru code gets submitted.
2. The current tools are converted over to using the pass thru,
3. The marshaling code using nd_cmd_in_size etc., would then be removed.

Quoted 4 lines

Quoted 1 line
Are you wanting to make one big change and not in separate steps?
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?

Quoted 3 lines

plus quibbling about the name "ND_CMD_PASSTHRU". Given the plans to eventually replace the existing commands we can call it something like 'ND_DSM_GENERIC'.

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?

Signature · 3 lines

-----------------------------------------------------------------------------
Jerry Hoemann            Software Engineer      Hewlett-Packard Enterprise
-----------------------------------------------------------------------------

Dan Williams

2015-11-17 17:05 UTC #8 lore raw

Quoted 35 lines · Jerry Hoemann

Quoted 5 lines · Dan Williams
Quoted 4 lines · Jerry Hoemann
Quoted 3 lines · Dan Williams
Quoted 1 line · Jerry Hoemann
...
Quoted 26 lines
Quoted 11 lines
Quoted 5 lines
Let's not do the _intel vs _passthru split. I want to convert the existing commands over to this new interface and deprecate the old ioctl-command formats. I.e. it isn't the case that this will be a always be a blind "passthru" mechanism, the kernel will need to crack open this payload in some circumstances.
I'm confused.
In this version there is only 1 ioctl 'N'. The pass thru is using number 100. This is what I thought you wanted from prior comments.
It is indeed, I like that change.
Quoted 12 lines
The split are for internal functions that deal specifically w/ the argument marshaling code and copy-in/copy-out. These mechanisms are different.
I understand that you want to switch over, but don't you (at least for the time being) need to keep the old marshaling code for the current
use case? I was assuming a sequence like:
1. The pass thru code gets submitted.
2. The current tools are converted over to using the pass thru,
3. The marshaling code using nd_cmd_in_size etc., would then be removed.

Quoted 6 lines

Quoted 4 lines
Quoted 1 line
Are you wanting to make one big change and not in separate steps?
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.

Quoted 5 lines

Quoted 3 lines
plus quibbling about the name "ND_CMD_PASSTHRU". Given the plans to eventually replace the existing commands we can call it something like 'ND_DSM_GENERIC'.

Quoted 8 lines

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?

Jerry Hoemann

author

2015-11-18 07:01 UTC #9 lore raw

Quoted 10 lines · Dan Williams

Quoted 9 lines · Jerry Hoemann
Quoted 5 lines · Dan Williams
Quoted 4 lines · Jerry Hoemann
Quoted 3 lines · Dan Williams
Quoted 1 line · Jerry Hoemann
...

Quoted 7 lines

Quoted 4 lines
Quoted 2 lines
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?

Quoted 12 lines

Quoted 12 lines
Quoted 4 lines
plus quibbling about the name "ND_CMD_PASSTHRU". Given the plans to eventually replace the existing commands we can call it something like 'ND_DSM_GENERIC'.
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?)

Quoted 6 lines

Quoted 2 lines
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.

Signature · 3 lines

-----------------------------------------------------------------------------
Jerry Hoemann            Software Engineer      Hewlett-Packard Enterprise
-----------------------------------------------------------------------------