public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Darren Hart <dvhart@infradead.org>
Cc: "Christoph Hellwig" <hch@infradead.org>,
	"Pali Rohár" <pali.rohar@gmail.com>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"Mario Limonciello" <mario_limonciello@dell.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Rafael Wysocki" <rjw@rjwysocki.net>,
	"Andy Lutomirski" <luto@amacapital.net>,
	LKML <linux-kernel@vger.kernel.org>,
	platform-driver-x86@vger.kernel.org
Subject: Re: WMI and Kernel:User interface
Date: Tue, 13 Jun 2017 18:52:47 +0200	[thread overview]
Message-ID: <20170613165247.GA32546@kroah.com> (raw)
In-Reply-To: <20170613162242.GF27850@fury>

On Tue, Jun 13, 2017 at 09:22:42AM -0700, Darren Hart wrote:
> On Tue, Jun 13, 2017 at 05:50:00PM +0200, Greg Kroah-Hartman wrote:
> > > 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.
> 
> Up to 2-3 months, the average would be shorter of course, as you say.
> 
> > 
> > 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.
> 
> I'd be very interested to hear more accounts of timeline to distro
> inclusion - if it is truly 1-2 days, I need to re-evaluate my position
> on this. I don't see how it could be without that being done out of band
> with mainline, which would in turn accrue technical debt which had to
> be managed each release.

Of course you do it out-of-band for mainline.  You send it upstream and
to the distro at the same time.  The team responsible for getting the
platform up and running for the preinstall merges it into the distro
kernel that gets shipped with the device, and all is well.  The next
update that the device gets, the patch is still there and when the
kernel gets updated, it's already merged.

This is what companies do all the time, they aren't running mainline on
a preinstall :)

> > 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.
> 
> As a concrete example, Dell has specifically made the request that we
> work on a solution that doesn't require them to come back to the kernel
> community each time they add a WMI GUID to their BIOS. They would like
> to see those GUIDs automatically exposed.

What do you mean exactly by "exposed"?  What do they do with these?  Why
isn't the Dell pre-install team sending patches for this like the
Windows preinstall team is doing for their hacked-to-hell copy of
Windows?  :)

Do you have an example patch of something that was needed to get a Dell
laptop working for a new device id that didn't work this way?

thanks,

greg k-h

  reply	other threads:[~2017-06-13 16:52 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-09 23:16 WMI and Kernel:User interface Darren Hart
2017-05-10  5:13 ` Greg Kroah-Hartman
2017-05-10  6:11   ` Darren Hart
2017-05-10 22:02     ` Mario.Limonciello
2017-05-10 22:11       ` Darren Hart
2017-05-10 22:50       ` Andy Lutomirski
2017-05-10 23:23         ` Darren Hart
2017-05-10 23:27       ` Darren Hart
2017-06-03 19:50   ` Darren Hart
2017-06-09  6:41     ` Greg Kroah-Hartman
2017-06-10  0:46       ` Darren Hart
2017-06-10 10:36         ` Pali Rohár
2017-06-12 17:02           ` Darren Hart
2017-06-12 22:17             ` Pali Rohár
2017-06-13  1:24               ` Darren Hart
2017-06-13  7:05                 ` Christoph Hellwig
2017-06-13 12:07                   ` Pali Rohár
2017-06-13 15:44                     ` Darren Hart
2017-06-13 16:05                       ` Greg Kroah-Hartman
2017-06-13 16:24                         ` Darren Hart
2017-06-13 15:38                   ` Darren Hart
2017-06-13 15:50                     ` Greg Kroah-Hartman
2017-06-13 15:56                       ` Andy Lutomirski
2017-06-13 16:12                         ` Mario.Limonciello
2017-06-13 16:57                           ` Greg KH
2017-06-13 17:43                             ` Pali Rohár
2017-06-13 16:39                         ` Darren Hart
2017-06-13 16:22                       ` Darren Hart
2017-06-13 16:52                         ` Greg Kroah-Hartman [this message]
2017-06-13 17:07                           ` Darren Hart
2017-06-14  4:38                             ` Greg Kroah-Hartman
2017-06-19 22:10                               ` Andy Lutomirski
2017-06-20  3:37                                 ` Darren Hart
2017-06-20  7:29                                   ` Pali Rohár
2017-06-13 17:16                     ` Pali Rohár
2017-06-13 17:40                       ` Darren Hart
2017-06-13 18:00                         ` Pali Rohár
2017-06-13 18:09                           ` Darren Hart
2017-06-14  0:28                         ` Bernd Petrovitsch
2017-06-13 12:51                 ` Pali Rohár
2017-06-13 16:07                   ` Darren Hart
2017-06-19 21:24 ` Matthew Garrett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170613165247.GA32546@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=dvhart@infradead.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mario_limonciello@dell.com \
    --cc=pali.rohar@gmail.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox