Date:   Tue, 13 Jun 2017 16:12:41 +0000
From:   <Mario.Limonciello@...l.com>
To:     <luto@...nel.org>, <gregkh@...uxfoundation.org>
CC:     <dvhart@...radead.org>, <hch@...radead.org>,
        <pali.rohar@...il.com>, <torvalds@...ux-foundation.org>,
        <andriy.shevchenko@...ux.intel.com>, <rjw@...ysocki.net>,
        <linux-kernel@...r.kernel.org>,
        <platform-driver-x86@...r.kernel.org>
Subject: RE: WMI and Kernel:User interface

> -----Original Message-----
> From: Andy Lutomirski [mailto:luto@...nel.org]
> Sent: Tuesday, June 13, 2017 10:57 AM
> To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Cc: Darren Hart <dvhart@...radead.org>; Christoph Hellwig <hch@...radead.org>;
> Pali Rohár <pali.rohar@...il.com>; Linus Torvalds <torvalds@...ux-
> foundation.org>; Limonciello, Mario <Mario_Limonciello@...l.com>; Andy
> Shevchenko <andriy.shevchenko@...ux.intel.com>; Rafael Wysocki
> <rjw@...ysocki.net>; LKML <linux-kernel@...r.kernel.org>; platform-driver-
> x86@...r.kernel.org
> Subject: Re: WMI and Kernel:User interface
> 
> On Tue, Jun 13, 2017 at 8:50 AM, Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> > On Tue, Jun 13, 2017 at 08:38:57AM -0700, Darren Hart wrote:
> >> On Tue, Jun 13, 2017 at 12:05:35AM -0700, Christoph Hellwig wrote:
> >> > Hi Darren,
> >> >
> >> > first - can you please properly trim your replies and don't write
> >> > more than 7 characters per line?
> >>
> >> Sure... (although I think you've done all the necessary pruning for this
> >> response). 70 I presume you mean? I usually have tw set to 72...
> >> apparently I dropped that setting at some point. Will correct.
> >>
> >> >
> >> > On Mon, Jun 12, 2017 at 06:24:35PM -0700, Darren Hart wrote:
> >> > > This is a big topic for sure. Speed and scale of platform enabling is something
> >> > > I would like to see us support better. The barrier to entry to kernel
> >> > > changes is high, especially for trivial things, like adding IDs, GUIDs, etc.
> >> > > which would ideally, IMHO, be in the hands of the OEMs.
> >> >
> >> > It's not.  It's a trivial patch, and you cover all Linux users.  Very
> >> > much unlike say the windows world where you are stuck with installing
> >> > a vendor specific set of drivers forever.
> >> >
> >>
> >> The patch is trivial, but the process is time consuming. Two to Three
> >> months to see an ID added and released is big blocker for contemporary
> >> life cycles.
> >
> > Wait, what?  Please explain.
> >
> > Yes, it could take worse case 2-3 months to add a new device id, but
> > does it really?  I take new device ids up until 2 weeks before a -final
> > kernel is released.  And once they are in Linus's tree it's usually only
> > a single week before they end up in all stable kernel releases.
> >
> > But that's upstream, no device ships with upstream, they ship a distro
> > kernel.  Look at the pre-installs from SuSE and Canonical, to get a new
> > device id into their kernels takes what, a day or two?  And that is what
> > really matters as that is what goes out the door for their device.
> >
> > At least that is the process for when _I_ used to work on pre-installed
> > Linux on devices, maybe things have gotten a lot worse since I left that
> > business, but I would sure hope it wouldn't get magnitudes worse.
> >
> > So 2-3 months seems really long to me.
> >
> 

Unless you catch the cycle just right, 8 weeks is normal for the delay to 
get a patch through a distro to an end user's machine.
They go through their own stable testing and let it bake before it's promoted.

> I should add that one thing that's really, really nice about Linux is
> that, when you install it on a supported laptop, it works.  On
> Windows, you end up with a horrible pile of bloated, buggy,
> unsupported userspace crapware to make random buttons work.
> 
> While I'm all for improving the managability situation on Linux, let's
> please make sure we don't regress the ordinary laptop functionality
> story and make it as bad as it is on Windows.  We're currently in a
> surprising situation in which laptops frequently work *better* on
> Linux than Windows, and I think we should preserve that.

So it's worth mentioning the main impetus for this (at least from my
company's perspective - but I expect others would share it) is to
make manageability work out of the box without having to install
additional proprietary tools.

Getting there requires work in a few areas:
1) The OEM/IBV exports the methods and the MOF (in binary form)
that describes the objects that can be interacted with and what
kind of data needs to be sent.
2) Kernel needs to provide a way to userspace to get to this data
3) A userspace OMI provider needs to be developed to read the 
MOF and load the accessible objects into a repository.
4) OMI tools can then interact with the OMI repository.

On the Windows side, you can "in-box" do manageability if the
OEM has done <1> this way.  You can use tools like powershell
to directly interact with the OMI repository.

Why don't we want the same thing on the Linux side?  If you put
up extra barriers to have to add ID's to a whitelist you are introducing
delay and artificially making it more difficult for what?

Powered by blists - more mailing lists