linux-kernel - Re: [PATCH 01/14] dell-laptop: extract SMBIOS-related code to a separate module

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201602092012.07392@pali>
Date:	Tue, 9 Feb 2016 20:12:07 +0100
From:	Pali Rohár <pali.rohar@...il.com>
To:	Darren Hart <dvhart@...radead.org>
Cc:	Michał Kępień <kernel@...pniu.pl>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Richard Purdie <rpurdie@...ys.net>,
	Jacek Anaszewski <j.anaszewski@...sung.com>,
	Alex Hung <alex.hung@...onical.com>,
	platform-driver-x86@...r.kernel.org, linux-leds@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/14] dell-laptop: extract SMBIOS-related code to a separate module

On Tuesday 09 February 2016 17:51:06 Darren Hart wrote:
> On Tue, Feb 09, 2016 at 09:33:03AM +0100, Pali Rohár wrote:
> > On Monday 08 February 2016 13:42:10 Darren Hart wrote:
> > > Assuming the above is an accurate view, I don't see any reason to
> > > go beyond the minimal change to the existing SMBIOS code to make
> > > it a usable API. If the need arises, we can always make such
> > > optimizations and performance improvements later. This is an
> > > internal API and we can change it whenever we need to so long as
> > > we update the call sites.
> > 
> > Problem is that now smbios code from dell-laptop.c is moved into
> > dell-smbios.c and dell-smbios.h and LED subsystem starts using
> > dell-smbios.h. In this case I'm thinking that we have something
> > like API usable by other modules/subsystem. And I'm thinking if it
> > is not better to create "correct" API now instead rewriting code
> > in LED and platform subsystem again later... As this API needs to
> > provide just 1 function, send command to Dell SMBIOS I think that
> > API is still minimal. Currently we have another two functions
> > alloc/free buffer (needed for send).
> 
> The internal kernel API changes all the time, we are not bound to it
> beyond ensuring we update the internal users when we change it. I
> prefer not to introduce complexity until we have to.
> 
> 	buffer = dell_smbios_get_buffer();
> 	buffer->input[0] = token->location;
> 	buffer->input[1] = token->value;
> 	dell_smbios_send_request(1, 0);
> 	dell_smbios_release_buffer();
> 
> The get_buffer and release_buffer also include the locking which is
> necessary for a shared buffer. If you eliminate the shared buffer,
> then you have to have a local buffer, which adds back code to create
> the buffer, initializize it, free it if it's dynamic, etc.
> 
> So from that sense, Michał's API seems at least as concise as the
> alternative, and it introduces less change.

Ok. Then let's stay with it. I have not tested patches yet, but do not 
see anything wrong. So go ahead you can add my Reviewed-by.

-- 
Pali Rohár
pali.rohar@...il.com

Download attachment "signature.asc " of type "application/pgp-signature" (199 bytes)