On Thu, 2009-02-26 at 10:34 +0000, Jonathan Buzzard wrote: > Yes. You really don't understand the Toshiba Hardware Configuration > Interface. It is like making a old style BIOS INT 13 call. There are > potentially 2^16 possible calls, and there is no way to determine what > calls are valid on what laptop models other than a large lookup table. You mean there's no way of using dmi matching to do subsets of models? Is the A20 very much different from the A10? > You explain to an end user then that they cannot use their new Toshiba > laptop with their favourite Linux distribution without doing their own > kernel module, as the lookup table for what HCI calls are valid on their > laptop is not implemented in the kernel their distribution comes with. > > Is that the road you are proposing to go down? Because it is completely > divorced from reality and totally impractical. So your view of reality is to tell the user to install a userspace library, and perhaps another daemon, and then patch all the userspace tools to use your library as well as the kernel interfaces? I don't think so. > Why would I put code into the kernel code for changing the ownerstring > on my laptop. Something I might do a couple of times in the lifetime of > the laptop? Why would you want to do that? That's focusing on the couple of people on the planet using a laptop that know what an ownerstring is. > What other models of computers have Linux kernel drivers to change the > BIOS boot order, or any other random model specific BIOS setting? Leave that to the BIOS. Just because it can be done, doesn't mean it should be done. > How do you propose to deal with the dozens of HCI calls and the hundreds > of models of laptops, with not all HCI calls being valid on all models, > and with the potential for a HCI call on the wrong laptop to brick it > and yes this *DOES* happen? How many different HCI calls are there to increase the backlight brightness up by one unit? > Why if I install a distribution of Linux on my new Toshiba laptop should > I have to install a new kernel module and keep it updated to make some > change because the table specifying which HCI calls can be made is not > up to date in my distro's kernel? Dude, that happens all the time with other kernel modules. You see a patch on LKML saying "add product ID for foobuzz" and then it gets picked up by downstream as a patch until a new version is released. > > > I would be interested in what on earth makes you thing putting hundreds > > > of lines of code into a "proper" kernel driver as you put it is better > > > as it is simply not the Unix way. > > > > If the UNIX way is to expose raw devices /proc/toshiba and /dev/toshiba > > and then use userspace tools to poke random values in them, then get me > > back to Linux real quick. > > It is not the Unix or Linux way to put huge quantities of code like this > into the kernel. It is not necessary or desirable, you *will* create > local privilege escalation bugs if you attempt it. Will I? > > The way to do this in the Linux kernel is to > > use the existing kernel abstractions like backlight and power_supply > > using a proper kernel driver. > > The problem is your failing to understand the shear depth of possible > calls to the HCI interface. I am quite sure that a 10,000+ line kernel > module to implement all the HCI methods would be rejected upstream. > Somewhere I have an email from Alan Cox from a decade ago telling me > just that. That is why the current method was developed. You don't need all of them. You need backlight control, fan control, battery and maybe a few others. You don't need to interact with the EC in all possible ways. > Finally actual code wins. If you want all this in kernel space then stop > winging and implement it. The fact that nobody has in the last five > years clearly indicates that there is little will to do so. Well, I think the onus is on you to provide a proper kernel patch, rather than just exposing userspace to /dev/toshiba, afterall, that was the thing that's prompted my mail Richard. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
