From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751953AbdI0Tuy (ORCPT ); Wed, 27 Sep 2017 15:50:54 -0400 Received: from esa1.dell-outbound.iphmx.com ([68.232.153.90]:46750 "EHLO esa1.dell-outbound.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751776AbdI0Tuv (ORCPT ); Wed, 27 Sep 2017 15:50:51 -0400 From: X-LoopCount0: from 10.166.132.187 X-IronPort-AV: E=Sophos;i="5.42,446,1500958800"; d="scan'208";a="66657053" X-DLP: DLP_GlobalPCIDSS To: , , , CC: , , , Subject: RE: [PATCH 06/12] platform/x86: dell-wmi-smbios: Add a sysfs interface for SMBIOS tokens Thread-Topic: [PATCH 06/12] platform/x86: dell-wmi-smbios: Add a sysfs interface for SMBIOS tokens Thread-Index: AQHTNhqxkSn0H9szfkuV8OzZLWWcOaLGKEWA//+w9KCAA2/wgP//w76ggABYdYCAAAaOAIAADwoA//+sfUA= Date: Wed, 27 Sep 2017 19:50:49 +0000 Message-ID: <7c2e7a1dc9864acfbe7eb78900f4748e@ausx13mpc120.AMER.DELL.COM> References: <1342f21a4f2c9af86d3033a9af9d9a4d05d27106.1505999739.git.mario.limonciello@dell.com> <20170925162333.GL22190@pali> <20170927165051.GE23572@fury> <20170927185514.GN23572@fury> <3a5a8de9-0a5b-45ad-73c6-6b3ebfdd5ebb@kernel.org> In-Reply-To: <3a5a8de9-0a5b-45ad-73c6-6b3ebfdd5ebb@kernel.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.143.18.86] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id v8RJoxjN016152 > -----Original Message----- > From: Andy Lutomirski [mailto:luto@kernel.org] > Sent: Wednesday, September 27, 2017 3:49 PM > To: Darren Hart ; Andy Shevchenko > ; Andy Lutomirski > Cc: Limonciello, Mario ; Pali Rohár > ; linux-kernel@vger.kernel.org; Platform Driver driver-x86@vger.kernel.org>; quasisec@google.com > Subject: Re: [PATCH 06/12] platform/x86: dell-wmi-smbios: Add a sysfs interface > for SMBIOS tokens > > On 09/27/2017 11:55 AM, Darren Hart wrote: > > On Wed, Sep 27, 2017 at 09:31:47PM +0300, Andy Shevchenko wrote: > >> On Wed, Sep 27, 2017 at 9:27 PM, wrote: > >> > >>>>>>> Darren, Andy, any comments? I'm not quite sure if such API is suitable > >>>>>>> for long term in kernel. > >>>>>> > >>>>>> I would try to avoid sysfs interfaces for some particular devices. > >>>>>> Besides we are creating a character device. Would it be suitable there? > >>>>> > >>>>> If the character device having 2 different ioctls for different needs is > >>>>> acceptable I'm happy to adjust the series to do this instead. > >>>> > >>>> One piece of feedback I had re the char device was to see if we could avoid the > >>>> need for the IOCTL altogether, I'd like to have that discussion before we add > >>>> another. > >>> > >>> My original design was sysfs files for everything but it was raised by several > folks > >>> that you run into the potential of two userspace processes stomping on each > >>> other's data when they run the ACPI call. That's why I need to have a mutex to > >>> protect and make sure that userspace calls get the right results. > >>> > >> > >>>>>>> Basically tokens are list of tuples with > >>>>>>> possibility to active them, right? > >>>>>>> > >>>>> > >>>>> I didn't add a way to activate them through this, it was only for > >>>>> reading purpose. Activating them should be possible through the > >>>>> SMBIOS calling interface though. > >>>>> > >>>> > >>>> These are read-only as I understood it, and only with the right privileges. > >>>> Sysfs seemed appropriate for this to me. > >>> > >>> Andy S was against having this data as another sysfs file. From a userspace > >>> perspective I think it's simpler to just parse a sysfs file with read only static > >>> data as root. With the current ioctl based solution it requires userspace to run > >>> an ioctl to determine how many tokens exist, then allocate a chunk of memory > >>> big enough to hold all the token data and then run another ioctl to get all the > tokens. > >>> > >>> Andy S, given this change between v1 and v2 what do you feel is better? > >> > >> I have no strong opinion on this. That's why I recommended to listen to Andy L. > > > > +Andy Lutomirski > > > > Andy L, any preference on your part regarding exporting these tokens via sysfs > > or through an additional IOCTL in the chardev? > > > > Not really. If this is indeed static data that is potentially useful > for scripts and such, than sysfs is kind of nice. OK thanks. I'll switch back to sysfs for v3.