thinkpad-wmi
thinkpad-wmi copied to clipboard
iksaif
LKML: access through char device and userspace utility/script
IMHO the driver should only have the minimal needed set of functionality. Someone at LKML suggested having a char device (e.g. /dev/thinkpad-bios). We could implement this, remove any additional stuff from the driver and have a user space utility to control /dev/thinkpad-bios.
Opinions?
Most of the existing stuff could stay in debugfs and we could add /dev/thinkpad-bios.
But wasn't the long term plan to somehow make wmi accessible from userspace ? (and most of what is in this driver would simply be moved to a small command line utility).
Maybe I misunderstood this: "But wasn't the long term plan to somehow make wmi accessible from userspace ? (and most of what is in this driver would simply be moved to a small command line utility)."
Isn't that what I said above? What exactly do you mean by "make wmi accessible from userspace"?
I meant, in a more generic way that asking everybody to add custom character devices. Could you answer back to the thread and check with them if a character device would be ok ? (to be sure you don't work on something that would get rejected)
A char device should be ok but the device should be /dev/wmi/thinkpad-bios. The same is done in dell-smbios-wmi: https://github.com/torvalds/linux/blob/master/Documentation/ABI/testing/dell-smbios-wmi
Look at Andy's and Darren's response:
The big notable differences with how we're approaching our drivers:
- GUID's that provide methods are given direct execution paths in sysfs files through your patch. This means that there could be a ton of different sysfs attributes that vary from vendor to vendor based on what they offer. I set up a concept that method type GUID's would be handled by the WMI bus by creating a character device in the /dev/wmi and copying in/out data for those method objects.
Wouldn't that be a little harder to use from userspace ? (But I can see how it makes it more generic).
Yes, it doesn't provide as discoverable an interface, now one that is as easy to use from the shell. However, it does so through sysfs and a defined character device rather than through debugfs, and can be relied upon by applications to exist.
From a vendors perspective, this is an important distinction - especially for things like bios settings, passwords, etc. which tend to be of value in enterprise deployments, where something like debugfs is not going to be enabled.
That means we should remove debugfs as well as all the settings stuff from sysfs and only keep the WMI methods. The driver shall be only a minimal interface without any further logic that will be done in userspace then.
Maybe debugfs could be kept for... well... debugging. I don't know. (AFAIK no other wmi driver has this)