> -----Original Message----- > From: Darren Hart [mailto:dvhart@xxxxxxxxxxxxx] > Sent: Wednesday, September 27, 2017 1:00 PM > To: Limonciello, Mario <Mario_Limonciello@xxxxxxxx> > Cc: andy.shevchenko@xxxxxxxxx; pali.rohar@xxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; platform-driver-x86@xxxxxxxxxxxxxxx; > quasisec@xxxxxxxxxx > Subject: Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character > device for userspace > > On Mon, Sep 25, 2017 at 05:46:54PM +0000, Mario.Limonciello@xxxxxxxx wrote: > > > -----Original Message----- > > > From: Andy Shevchenko [mailto:andy.shevchenko@xxxxxxxxx] > > > Sent: Monday, September 25, 2017 12:58 PM > > > To: Pali Rohár <pali.rohar@xxxxxxxxx> > > > Cc: Limonciello, Mario <Mario_Limonciello@xxxxxxxx>; dvhart@xxxxxxxxxxxxx; > > > LKML <linux-kernel@xxxxxxxxxxxxxxx>; Platform Driver <platform-driver- > > > x86@xxxxxxxxxxxxxxx>; quasisec@xxxxxxxxxx > > > Subject: Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character > > > device for userspace > > > > > > On Mon, Sep 25, 2017 at 7:31 PM, Pali Rohár <pali.rohar@xxxxxxxxx> wrote: > > > > On Thursday 21 September 2017 08:57:16 Mario Limonciello wrote: > > > >> This userspace character device will be used to perform SMBIOS calls > > > >> from any applications sending a properly formatted 4k calling interface > > > >> buffer. > > > >> > > > >> This character device is intended to deprecate the dcdbas kernel module > > > >> and the interface that it provides to userspace. > > > >> > > > >> It's important for the driver to provide a R/W ioctl to ensure that > > > >> two competing userspace processes don't race to provide or read each > > > >> others data. > > > > > > >> +What: /dev/wmi-dell-wmi-smbios > > > > > > > > What about just /dev/dell-smbios? IOCTL provided here is just SMBIOS > > > > related and I think userspace does not have to care if it is via WMI or > > > > direct SMM mode... Important is that it provides character device for > > > > SMBIOS API and not how it is implemented. > > I agree with this point, the implementation (WMI under the covers) is > not relevant. That said, this is an example of exposing WMI > functionality to userspace, and I DO NOT want to have a naming > discussion for every single WMI GUID that we choose to expose. Yes, I agree let's make sure it's stable and automatic for all drivers that will use it. > > > > > > > > > Anyway, Darren, Andy, do we have some convention for naming platform > > > > character devices? > > > > > > For me, looking to this case, seems better to expose a folder like > > > /dev/smbios/ > > > with actual vendor device nodes inside like > > > /dev/smbios/dell > > > > I disagree with this. Dell exposes smbios calling in this kernel interface but > > other vendor drivers may also expose different methods for character devices > > that are not SMBIOS. > > > > I'm envisioning that this is just the first kernel module that will use a WMI > > character device to userspace. That's why I wanted to use a generic namespace. > > > > I would say it could be /dev/wmi-$GUID or /dev/wmi/$driver-$GUID if you want > > something more generic. > > As long as it's discovereable from uevent that's fine to me. > > > > > > > > Darren? > > I would like to see an automated and definiitive way to export WMI > GUIDs. Something we can look at, compare to a set of rules, and say > yay/nay. From that perspective, I like Mario's general proposal. It is > not clear to me if the $driver- prefix adds any value though - would we > ever have need of DRIVER_X-GUID_A and DRIVER_Y-GUID_A ??? I'm thinking > not. > > /dev/wmi/$GUID > I don't think you should allow two drivers to use the same GUID, but what if a driver needs to use multiple GUIDs? This obviously isn't a problem yet. I envision that as we get MOF interpretation as part of the bus we "may" get into that situation with more complicated MOF design. The vendor driver could register with the bus for each GUID and request a character device for each but that's meaning userspace has to worry about knowing which GUIDs do what. I think it's potentially asking for a complicated interface to userspace for the future. Here's a hypothetical scenario based on some more advanced MOF design I know of: Separate GUID provided for each: * All integer settings (data type) * All string settings (data type) * Notifications (event type) * enumeration types (data type) * Applying a Setting (method type) * Managing users (method type) How would a new driver for that look? I would think you would want one driver to register and encapsulate at least all of those GUIDs. I would say all the data should be exported into sysfs, but that you really only want one character device that is used for both methods. The interface to userspace would then have two IOCTL's that the driver would internally apply to the correct GUID. Example: "/dev/wmi/$driver" supports 2 different IOCTL's. Internally the driver would then ferry the request through the WMI bus to the correct GUID based on the ioctl call number. If you went with the pass the GUID information up and create character device for each GUID, userspace will have to know: "I use /dev/wmi/$GUID_X" for applying the setting IOCTL on Acme Inc machine. And "I use /dev/wmi/$GUID_Y" for managing users IOCTL on Acme Inc machine. And what if the notifications are valuable to userspace? Would you want to create another character device for those? I think you would just want to keep them in the same device and add a poll/select file operation.
