All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Scott Bauer <scott.bauer@intel.com>
Cc: linux-nvme@lists.infradead.org, keith.busch@intel.com,
	sagi@grimberg.me, hch@infradead.org, Rafael.Antognolli@intel.com,
	linux-kernel@vger.kernel.org, axboe@fb.com,
	viro@zeniv.linux.org.uk, jonathan.derrick@intel.com
Subject: Re: [PATCH v3 1/5] include: Add definitions for sed
Date: Mon, 19 Dec 2016 22:46:12 -0800	[thread overview]
Message-ID: <20161220064612.GA13844@infradead.org> (raw)
In-Reply-To: <1482176149-2257-2-git-send-email-scott.bauer@intel.com>

On Mon, Dec 19, 2016 at 12:35:45PM -0700, Scott Bauer wrote:
> This patch adds the definitions and structures for the SED
> Opal code.

This seems to contain a few things:  userspace ABIs, on the wire
defintions, and prototypes for the code added in patch 2.

The userspace ABIs should be a header on it's own.  For new code
we also usually try to split the protocol definitions from the
in-kernel APIs, although that's not even reflected in the headers
here.  If you think it's reasonable to split those out those should
be a separate new patch, and the actual in-kernel data structures
and protoypes should just go with the actual code in your current patch
2.

> +/**
> + * struct sed_context - SED Security context for a device
> + * @ops:The Trusted Send/Recv functions.
> + * @sec_data:Opaque pointer that will be passed to the send/recv fn.
> + *Drivers can use this to pass necessary data required for
> + *Their implementation of send/recv.
> + * @dev:Currently an Opal Dev structure. In the future can be other types
> + *Of security structures.
> + */

This is missing a couple spaces for the common kerneldoc format.

> +struct sed_context {
> +	const struct sec_ops *ops;
> +	void *sec_data;
> +	void *dev;
> +};

What is the difference between sec_data and dev?  And do your really
need either one when using the container_of trick I pointed out in
response to the other patch.

> +struct sed_key {
> +	__u32 sed_type;
> +	union {
> +		struct opal_key            opal;
> +		struct opal_new_pw         opal_pw;
> +		struct opal_session_info   opal_session;
> +		struct opal_user_lr_setup  opal_lrs;
> +		struct opal_lock_unlock    opal_lk_unlk;
> +		struct opal_mbr_data       opal_mbr;
> +		/* additional command set key types */
> +	};
> +};
> +
> +#define IOC_SED_SAVE		   _IOW('p', 220, struct sed_key)
> +#define IOC_SED_LOCK_UNLOCK	   _IOW('p', 221, struct sed_key)
> +#define IOC_SED_TAKE_OWNERSHIP	   _IOW('p', 222, struct sed_key)
> +#define IOC_SED_ACTIVATE_LSP       _IOW('p', 223, struct sed_key)
> +#define IOC_SED_SET_PW             _IOW('p', 224, struct sed_key)
> +#define IOC_SED_ACTIVATE_USR       _IOW('p', 225, struct sed_key)
> +#define IOC_SED_REVERT_TPR         _IOW('p', 226, struct sed_key)
> +#define IOC_SED_LR_SETUP           _IOW('p', 227, struct sed_key)
> +#define IOC_SED_ADD_USR_TO_LR      _IOW('p', 228, struct sed_key)
> +#define IOC_SED_ENABLE_DISABLE_MBR _IOW('p', 229, struct sed_key)
> +#define IOC_SED_ERASE_LR           _IOW('p', 230, struct sed_key)
> +#define IOC_SED_SECURE_ERASE_LR    _IOW('p', 231, struct sed_key)

I'll need to look at the details again, but it seems like each ioctl
uses exactly one of the structures in the union above, so there is no
real need for that union.

WARNING: multiple messages have this Message-ID (diff)
From: hch@infradead.org (Christoph Hellwig)
Subject: [PATCH v3 1/5] include: Add definitions for sed
Date: Mon, 19 Dec 2016 22:46:12 -0800	[thread overview]
Message-ID: <20161220064612.GA13844@infradead.org> (raw)
In-Reply-To: <1482176149-2257-2-git-send-email-scott.bauer@intel.com>

On Mon, Dec 19, 2016@12:35:45PM -0700, Scott Bauer wrote:
> This patch adds the definitions and structures for the SED
> Opal code.

This seems to contain a few things:  userspace ABIs, on the wire
defintions, and prototypes for the code added in patch 2.

The userspace ABIs should be a header on it's own.  For new code
we also usually try to split the protocol definitions from the
in-kernel APIs, although that's not even reflected in the headers
here.  If you think it's reasonable to split those out those should
be a separate new patch, and the actual in-kernel data structures
and protoypes should just go with the actual code in your current patch
2.

> +/**
> + * struct sed_context - SED Security context for a device
> + * @ops:The Trusted Send/Recv functions.
> + * @sec_data:Opaque pointer that will be passed to the send/recv fn.
> + *Drivers can use this to pass necessary data required for
> + *Their implementation of send/recv.
> + * @dev:Currently an Opal Dev structure. In the future can be other types
> + *Of security structures.
> + */

This is missing a couple spaces for the common kerneldoc format.

> +struct sed_context {
> +	const struct sec_ops *ops;
> +	void *sec_data;
> +	void *dev;
> +};

What is the difference between sec_data and dev?  And do your really
need either one when using the container_of trick I pointed out in
response to the other patch.

> +struct sed_key {
> +	__u32 sed_type;
> +	union {
> +		struct opal_key            opal;
> +		struct opal_new_pw         opal_pw;
> +		struct opal_session_info   opal_session;
> +		struct opal_user_lr_setup  opal_lrs;
> +		struct opal_lock_unlock    opal_lk_unlk;
> +		struct opal_mbr_data       opal_mbr;
> +		/* additional command set key types */
> +	};
> +};
> +
> +#define IOC_SED_SAVE		   _IOW('p', 220, struct sed_key)
> +#define IOC_SED_LOCK_UNLOCK	   _IOW('p', 221, struct sed_key)
> +#define IOC_SED_TAKE_OWNERSHIP	   _IOW('p', 222, struct sed_key)
> +#define IOC_SED_ACTIVATE_LSP       _IOW('p', 223, struct sed_key)
> +#define IOC_SED_SET_PW             _IOW('p', 224, struct sed_key)
> +#define IOC_SED_ACTIVATE_USR       _IOW('p', 225, struct sed_key)
> +#define IOC_SED_REVERT_TPR         _IOW('p', 226, struct sed_key)
> +#define IOC_SED_LR_SETUP           _IOW('p', 227, struct sed_key)
> +#define IOC_SED_ADD_USR_TO_LR      _IOW('p', 228, struct sed_key)
> +#define IOC_SED_ENABLE_DISABLE_MBR _IOW('p', 229, struct sed_key)
> +#define IOC_SED_ERASE_LR           _IOW('p', 230, struct sed_key)
> +#define IOC_SED_SECURE_ERASE_LR    _IOW('p', 231, struct sed_key)

I'll need to look at the details again, but it seems like each ioctl
uses exactly one of the structures in the union above, so there is no
real need for that union.

  reply	other threads:[~2016-12-20  6:46 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-19 19:35 [PATCH v3 0/5] SED OPAL Library Scott Bauer
2016-12-19 19:35 ` Scott Bauer
2016-12-19 19:35 ` [PATCH v3 1/5] include: Add definitions for sed Scott Bauer
2016-12-19 19:35   ` Scott Bauer
2016-12-20  6:46   ` Christoph Hellwig [this message]
2016-12-20  6:46     ` Christoph Hellwig
2016-12-25 14:15   ` Jethro Beekman
2016-12-25 14:15     ` Jethro Beekman
2016-12-27 22:14     ` Scott Bauer
2016-12-27 22:14       ` Scott Bauer
2016-12-19 19:35 ` [PATCH v3 2/5] lib: Add Sed-opal library Scott Bauer
2016-12-19 19:35   ` Scott Bauer
2016-12-19 21:34   ` Keith Busch
2016-12-19 21:34     ` Keith Busch
2016-12-20  6:07     ` Christoph Hellwig
2016-12-20  6:07       ` Christoph Hellwig
2016-12-20  3:21   ` kbuild test robot
2016-12-20  3:21     ` kbuild test robot
2016-12-20  3:48   ` kbuild test robot
2016-12-20  3:48     ` kbuild test robot
2016-12-20  6:50   ` Al Viro
2016-12-20  6:50     ` Al Viro
2016-12-20  7:28   ` Christoph Hellwig
2016-12-20  7:28     ` Christoph Hellwig
2016-12-20 21:55     ` Scott Bauer
2016-12-20 21:55       ` Scott Bauer
2016-12-21  9:42       ` Christoph Hellwig
2016-12-21  9:42         ` Christoph Hellwig
2016-12-20 22:07     ` Jon Derrick
2016-12-20 22:07       ` Jon Derrick
2016-12-21  9:47       ` Christoph Hellwig
2016-12-21  9:47         ` Christoph Hellwig
2016-12-19 19:35 ` [PATCH v3 3/5] fs: Wire up SED/Opal to ioctl Scott Bauer
2016-12-19 19:35   ` Scott Bauer
2016-12-20  6:21   ` Christoph Hellwig
2016-12-20  6:21     ` Christoph Hellwig
2016-12-19 19:35 ` [PATCH v3 4/5] nvme: Implement resume_from_suspend and SED Allocation code Scott Bauer
2016-12-19 19:35   ` Scott Bauer
2016-12-19 21:59   ` Keith Busch
2016-12-19 21:59     ` Keith Busch
2016-12-19 22:23     ` Scott Bauer
2016-12-19 22:23       ` Scott Bauer
2016-12-20  6:17       ` Christoph Hellwig
2016-12-20  6:17         ` Christoph Hellwig
2016-12-20 15:49         ` Keith Busch
2016-12-20 15:49           ` Keith Busch
2016-12-20 15:46           ` Christoph Hellwig
2016-12-20 15:46             ` Christoph Hellwig
2016-12-20 16:05             ` Scott Bauer
2016-12-20 16:05               ` Scott Bauer
2016-12-21  9:01               ` Christoph Hellwig
2016-12-21  9:01                 ` Christoph Hellwig
2016-12-20 17:52             ` Scott Bauer
2016-12-20 17:52               ` Scott Bauer
2016-12-21  9:37               ` Christoph Hellwig
2016-12-21  9:37                 ` Christoph Hellwig
2016-12-20  4:11   ` kbuild test robot
2016-12-20  4:11     ` kbuild test robot
2016-12-20  6:21   ` Christoph Hellwig
2016-12-20  6:21     ` Christoph Hellwig
2016-12-20  6:49   ` Christoph Hellwig
2016-12-20  6:49     ` Christoph Hellwig
2016-12-25 14:15   ` Jethro Beekman
2016-12-25 14:15     ` Jethro Beekman
2016-12-27 22:12     ` Scott Bauer
2016-12-27 22:12       ` Scott Bauer
2016-12-28  8:39       ` Christoph Hellwig
2016-12-28  8:39         ` Christoph Hellwig
2016-12-19 19:35 ` [PATCH v3 5/5] Maintainers: Add Information for SED Opal library Scott Bauer
2016-12-19 19:35   ` Scott Bauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161220064612.GA13844@infradead.org \
    --to=hch@infradead.org \
    --cc=Rafael.Antognolli@intel.com \
    --cc=axboe@fb.com \
    --cc=jonathan.derrick@intel.com \
    --cc=keith.busch@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    --cc=scott.bauer@intel.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.