Message-ID: <20171013222847.GA4176@fury>
Date:   Fri, 13 Oct 2017 15:28:47 -0700
From:   Darren Hart <dvhart@...radead.org>
To:     Greg KH <greg@...ah.com>
Cc:     Mario.Limonciello@...l.com, gnomes@...rguk.ukuu.org.uk,
        andy.shevchenko@...il.com, linux-kernel@...r.kernel.org,
        platform-driver-x86@...r.kernel.org, luto@...nel.org,
        quasisec@...gle.com, pali.rohar@...il.com, rjw@...ysocki.net,
        mjg59@...gle.com, hch@....de
Subject: Re: [PATCH v7 10/15] platform/x86: dell-smbios: add filtering
 capability for requests

On Fri, Oct 13, 2017 at 05:56:03PM +0200, Greg KH wrote:
> Just want to respond to this part first:
> 
> On Fri, Oct 13, 2017 at 03:03:10PM +0000, Mario.Limonciello@...l.com wrote:
> > Take off your "kernel" hat and put on a "customer" hat for a few moments
> > while I try to put this in practical terms why the whitelist approach doesn't
> > scale for what I'm trying to do.
> 
> Heh, you do know my background in running an enterprise kernel team,
> right? :)
> 
> > Let's say hypothetically a future version of this series that has only whitelisted
> > commands and tokens lands in a kernel that's in the next Ubuntu LTS, RHEL
> > release etc.
> > Hardware coming out about that time works fine, you can control the various
> > knobs.  Then later that year some new headless hardware is released that has
> > zigbee controllers that work with inbox kernel drivers but you can't turn them 
> > on and off any way BUT through the manageability interface (it's headless!).
> > In the manageability interface we also offer a new class/select or token that 
> > can control the GPIO that turns on/off these radios.
> 
> It's the "later" that you are missing here.  We only have code today for
> hardware we have today.  If you come out with new hardware, you need new
> kernel drivers for it, and as such, "old" enterprise kernels will just
> not work properly.
> 
> It's always been that way, this is nothing new, we can't predict the
> future, and is one big reason why I think the whole "enterprise" distro
> market is wrong and going to fail in the end :)

Just because it's always been that way, doesn't mean it has to continue
to be that way. We have a few examples where we support implementing
what was formerly kernel space in userspace, such as FUSE and libusb.
The details are different, but the idea is the same. Allow people to do
things they need to do without having to modify the kernel.

> 
> Same goes for that new device id for the wifi chip, or the video camera
> or the fingerprint reader.  Those have to be added to the kernel, and if
> the distro so desires, backported to their old and crufty version.
> 
> This has been happening for two decades now, somehow coming up with a
> "raw" pipe from userspace to the kernel to control the hardware just
> because you don't want to update the kernel code, isn't going to solve
> the issue here (hint, you now have to update your userspace code, why is
> that suddenly easier than the kernel?)

Even if updating the kernel was just as easy as updating a management
application they control, that's still twice the work.

> I know hardware companies want to stop writing software for their new
> hardware designs.  I too want a pony :)
> 
> Sorry, this argument isn't going to fly.

Well... I don't think reducing the amount of software required to
support a new platform is a bad thing.

I'm curious for your take on Alan's CAPs recommendation.

-- 
Darren Hart
VMware Open Source Technology Center

Powered by blists - more mailing lists