On Fri, Dec 09, 2016 at 10:45:30AM -0700, Scott Bauer wrote:
> Now, with this in mind, it sort of makes sense to move this from
> block/ back into lib/ and interface with the character dev. Instead
> of passing around block_devices, we can pass around struct file *'s.
>
Even the character device
On Thu, Dec 01, 2016 at 01:22:39PM -0500, Keith Busch wrote:
> On Thu, Dec 01, 2016 at 10:53:43AM -0700, Scott Bauer wrote:
> > > Maybe. I need to look at the TCG spec again (oh my good, what a fucking
> > > mess), but if I remember the context if it is the whole nvme controller
> > > and not
On Thu, Dec 01, 2016 at 10:53:43AM -0700, Scott Bauer wrote:
> > Maybe. I need to look at the TCG spec again (oh my good, what a fucking
> > mess), but if I remember the context if it is the whole nvme controller
> > and not just a namespace, so a block_device might be the wrong context.
> > Then
On Thu, Dec 01, 2016 at 02:04:56AM -0800, Christoph Hellwig wrote:
> On Wed, Nov 30, 2016 at 07:50:07PM -0500, Keith Busch wrote:
> > I think we should get rid of the "majmin" stuff
>
> Absolutely agreed.
>
> >
> > and directly use
> > block_device. Then if we add the security send/receive
On Wed, Nov 30, 2016 at 07:50:07PM -0500, Keith Busch wrote:
> I think we should get rid of the "majmin" stuff
Absolutely agreed.
>
> and directly use
> block_device. Then if we add the security send/receive operations to the
> block_device_operations, that will simplify chaining the security
On Tue, Nov 29, 2016 at 02:52:00PM -0700, Scott Bauer wrote:
> +struct opal_dev {
> + dev_t majmin;
> + sed_sec_submit *submit_fn;
> + void *submit_data;
> + struct opal_lock_unlock lkul;
> + const opal_step *funcs;
> + void **func_data;
> + bool resume_from_suspend;
>
es1;4205;0cOn Wed, Nov 30, 2016 at 01:13:57PM -0500, Keith Busch wrote:
> On Tue, Nov 29, 2016 at 02:52:00PM -0700, Scott Bauer wrote:
> > + dev = get_or_create_opal_dev(bdev, key->opal_act.key.lr, true);
> > + if (!dev)
> > + return -ENOMEM;
>
> The alloc_opal_dev from this call
