lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 27 Sep 2017 08:43:07 -0700 From: Darren Hart <dvhart@...radead.org> To: Mario.Limonciello@...l.com Cc: pali.rohar@...il.com, linux-kernel@...r.kernel.org, platform-driver-x86@...r.kernel.org, quasisec@...gle.com Subject: Re: [PATCH 01/12] platform/x86: dell-wmi: label driver as handling notifications On Mon, Sep 25, 2017 at 08:14:00PM +0000, Mario.Limonciello@...l.com wrote: > > -----Original Message----- > > From: Pali Rohár [mailto:pali.rohar@...il.com] > > Sent: Monday, September 25, 2017 12:04 PM > > To: Limonciello, Mario <Mario_Limonciello@...l.com> > > Cc: dvhart@...radead.org; LKML <linux-kernel@...r.kernel.org>; platform-driver- > > x86@...r.kernel.org; quasisec@...gle.com > > Subject: Re: [PATCH 01/12] platform/x86: dell-wmi: label driver as handling > > notifications > > > > On Thursday 21 September 2017 08:57:06 Mario Limonciello wrote: > > > This driver serves the purpose of responding to WMI based notifications > > > from the DELL_EVENT_GUID (9DBB5994-A997-11DA-B012-B622A1EF5492). > > > Other GUIDs will be handled by separate drivers. > > > > > > Update the language used by this driver to avoid future confusion. > > > > Hi! I'm not sure if if "notifications" word is better then "extras". > > Basically the most important part of the dell-wmi driver is to deliver > > key press events via input device. > > > > Has anybody else better word or description for this? > > > I was actually tempted to rename the driver itself to dell-wmi-notifications. > Realistically it is hooking up to the notifications _WED0 AML method so yes > it is picking up notifications exclusively. > > I thought about this too, but I can also envision that the notifications that > come through this driver that aren't consumed by the kernel for keypress > purposes are also useful to user space potentially. It's not part of this series > but maybe in the future providing those through a character device too may > make sense. Naming is hard, but this seems like a reasonable refinement without over-specifying. -- Darren Hart VMware Open Source Technology Center
Powered by blists - more mailing lists