> -----Original Message----- > From: Greg KH [mailto:g...@kroah.com] > Sent: Tuesday, October 3, 2017 4:23 AM > To: Limonciello, Mario <mario_limoncie...@dell.com> > Cc: dvh...@infradead.org; Andy Shevchenko <andy.shevche...@gmail.com>; > LKML <linux-kernel@vger.kernel.org>; platform-driver-...@vger.kernel.org; > Andy Lutomirski <l...@kernel.org>; quasi...@google.com; > pali.ro...@gmail.com > Subject: Re: [PATCH v3 4/8] platform/x86: wmi: create character devices when > requested by drivers > > On Wed, Sep 27, 2017 at 11:02:16PM -0500, Mario Limonciello wrote: > > For WMI operations that are only Set or Query read or write sysfs > > attributes created by WMI vendor drivers make sense. > > > > For other WMI operations that are run on Method, there needs to be a > > way to guarantee to userspace that the results from the method call > > belong to the data request to the method call. Sysfs attributes don't > > work well in this scenario because two userspace processes may be > > competing at reading/writing an attribute and step on each other's > > data. > > > > When a WMI vendor driver declares a set of functions in a > > file_operations object the WMI bus driver will create a character > > device that maps to those file operations. > > > > That character device will correspond to this path: > > /dev/wmi/$driver > > > > This policy is selected as one driver may map and use multiple > > GUIDs and it would be better to only expose a single character > > device. > > > > The WMI vendor drivers will be responsible for managing access to > > this character device and proper locking on it. > > > > When a WMI vendor driver is unloaded the WMI bus driver will clean > > up the character device. > > Ok, thanks to Darren, I've gone and dug these up while my boxes were > building stable kernels... > > Why are you not just using the misc device interface here? Why do you > need a whole new major and minor range? Why not just register misc > devices dynamically as-needed? Should be much simpler and easier to > maintain and reduce your code size a lot. >
Thanks for this feedback. I'll look into this as an alternative.
