lkml.org 
[lkml]   [2020]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v3 07/18] nitro_enclaves: Init misc device providing the ioctl interface
    From
    Date
    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.


    \
     
     \ /
      Last update: 2020-06-01 04:53    [W:4.995 / U:0.164 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site