On Mon, Apr 01, 2019 at 05:25:11PM +0000, Jethro Beekman wrote: > On 2019-04-01 03:01, Jarkko Sakkinen wrote: > > On Fri, Mar 29, 2019 at 09:20:05AM -0700, Sean Christopherson wrote: > > > On Thu, Mar 28, 2019 at 12:05:39PM -0700, Andy Lutomirski wrote: > > > > On Thu, Mar 28, 2019 at 6:19 AM Jarkko Sakkinen > > > > <jarkko.sakkinen@xxxxxxxxxxxxxxx> wrote: > > > > > > > > > > On Wed, Mar 27, 2019 at 01:06:11PM -0700, Sean Christopherson wrote: > > > > > > I agree with all of the above, but unfortunately blacklisting is really > > > > > > the only benefit that would be realized by modularizing the driver. The > > > > > > "driver" at this point is just the device and its ioctls, the meat of > > > > > > the functionality has been moved into the subsystem proper. And the few > > > > > > remaining tidbits of functionality, e.g. sgx_encl_page_alloc() and > > > > > > sgx_encl_alloc(), probably should be moved out of ioctl.c as well. > > > > > > > > > > That is kind of core reason of having an LKM here, to wrap the uapi. It > > > > > is not about reducing size of the kernel. It is about ability to tailor > > > > > the uapi on stock kernels. > > > > > > > > > > > > > As I see it, there is really only one significant benefit of modules: > > > > reducing the size of the kernel in the case that the module isn't > > > > loaded. > > > > > > This is a much more succinct explanation of what I was attempting to say. > > > > > > > (And organizing module parameters, I suppose, but you don't, > > > > strictly speaking, need to be able to build as a module to do that.) > > > > SGX can be blacklisted by booting with nosgx (or, if if can't, then > > > > that should be added). > > > > > > The split lock detection series also proposed extending clearcpuid to > > > take flags by name, a dedicated 'nosgx' may not even be necessary in the > > > long run. > > > > > > https://lkml.kernel.org/r/1549084491-57808-6-git-send-email-fenghua.yu@xxxxxxxxx > > > https://lkml.kernel.org/r/1549084491-57808-7-git-send-email-fenghua.yu@xxxxxxxxx > > > https://lkml.kernel.org/r/1549084491-57808-8-git-send-email-fenghua.yu@xxxxxxxxx > > > > OK, that's great. Then I just rework the LKM out... > > Wait, why? I don't agree with Andy's "only" reason for LKMs, and it sounded > like you agree. For me the rationale for having LKM was that you can enable/disable the functionality. For that the kernel command line would be sufficient. I will roll v20 w/o taking it away since this is still clearly something not concluded (won't affect other changes). /Jarkko
