Messages in this thread | | | Subject | Re: [PATCH v3 07/18] nitro_enclaves: Init misc device providing the ioctl interface | From | Benjamin Herrenschmidt <> | Date | Mon, 01 Jun 2020 12:51:16 +1000 |
| |
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.
| |