On Tuesday 13 June 2017 00:05:35 Christoph Hellwig wrote: > 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. Yes, adding new GUID is same hard as adding new PCI ID or USB ID. It is really trivial patch. > > Ideally, we would provide a generic way for users/OEMs/vendors to successfully > > support and maintain their own platforms, ideally with as little kernel changes > > as possible. If we can get closer to that than we are today with this WMI work, > > I think that is worth the effort. > > Hell no! The last thing we need on Linux is systems that once support > us added don't just work out of the box because you're missing your > vendor blob. Seeing vendor blob compiled for one particular userspace and distribution which would be needed for having working notebook support on Linux is way to the hell. Here I agree with Christoph. > > > And filter layer which will accept only WMI calls which are safe for > > > currently loaded/used kernel modules seems like a sane idea to ensure > > > functionality of kernel plus allow userspace to do other things. > > > > My biggest concern with this approach is maintenance. Because we would be doing > > something unforeseen by the specification, the various vendor implemented WMI > > APIs are not likely to be amenable to filtering. I can see these filters > > getting extremely complicated. They are "high touch", by which I mean each > > generation of platform may require subtle tweaks, which will be difficult to > > verify they don't break past generations. > > Agreed. As mentioned before I think the only sensible approach is > white listing GUIDs that have a valid userspace use case. And use > the dynamic IDs approach to add them for debugging and reverse > engineering. In some cases filter function can be simple in some cases hard. I can image that usage of while listing, plus in some cases also filtering (when it would be relatively easy to implement). -- Pali Rohár pali.rohar@xxxxxxxxx
