> So I've been thinking more about this and to me this whole argument > sounds a lot like we just want to have our own little corner to > play in, without needing to worry about what other vendors do. > > And then Lenovo, and HP and who knows else will all want the same > and we and up with at least 5 different interfaces. > > It is bad enough that we already have to deal with having 5+ > different firmware interfaces for this and worse even for silly > things like setting the brightness level for the kbd backlight, > which is such a trivial thing that you would think PC vendors > should be able to sit down and agree on a single ACPI API for it. > > We are NOT going to take this lets all do our own thing approach and > also let this trickle up in the stack to the kernel <-> userspace API! > > One of the tasks of the kernel is to act as a HAL and this clearly > falls under that. Imagine if userspace code would need to use different > kernel APIs for storage/filesystem accesses depending on if they were > running on a Dell or a Lenovo machines. Or having different APIs to > access the network depending on the machine vendor... > > So I'm sorry, but I'm drawing a line in the sand here, unless you can > come up with some really convincing NEW arguments why this needs to > be a Dell specific interface, the Dell firmware-attributes code must > use a generic sysfs-ABI/class to get accepted upstream. > > Note that I think the currently suggested private Dell ABI is actually > pretty suitable for such a generic sysfs-ABI/class, so I'm not asking > you to make a lot of changes here. > > Regards, > > Hans We'll try this for the v4 patch series.
