Re: [PATCH v3 07/18] nitro_enclaves: Init misc device providing the ioctl interface

From: Benjamin Herrenschmidt
Date: Sun May 31 2020 - 22:51:43 EST


On Tue, 2020-05-26 at 14:44 +0200, Alexander Graf wrote:
> So I really don't think an ioctl would be a great user experience. Same
> for a sysfs file - although that's probably slightly better than the ioctl.

What would be wrong with a sysfs file ?

Another way to approach that makes sense from a kernel perspective is
to have the user first offline the CPUs, then "donate" them to the
driver via a sysfs file.

> Other options I can think of:
>
> * sysctl (for modules?)

Why would that be any good ? If anything sysctl's are even more awkward
in my book :)

> * module parameter (as implemented here)
> * proc file (deprecated FWIW)

Yeah no.

> The key is the tenant split: Admin sets the pool up, user consumes. This
> setup should happen (early) on boot, so that system services can spawn
> enclaves.

Right and you can have some init script or udev rule that sets that up
from a sys admin produced config file at boot upon detection of the
enclave PCI device for example.

> > module parameters are a major pain, you know this :)
>
> I think in this case it's the least painful option ;). But I'm really
> happy to hear about an actually good alternative to it. Right now, I
> just can't think of any.

Cheers,
Ben.