Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1331564

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

From Darren Hart <dvhart@infradead.org>
Newsgroups linux.kernel
Subject Re: [PATCH 01/14] dell-laptop: extract SMBIOS-related code to a separate module
Date 2016-02-11 00:10 +0100
Message-ID <r0M3w-pI-3@gated-at.bofh.it> (permalink)
References <qQ7O1-1Z5-3@gated-at.bofh.it> <r0c01-1wH-5@gated-at.bofh.it> <r0jNV-6Mt-27@gated-at.bofh.it> <r0lZp-8lW-23@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Tue, Feb 09, 2016 at 08:12:07PM +0100, Pali Rohár wrote:
> 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.

Great. Thank you Pali.

This has been queued to testing.

Thank you all for your diligence in getting this series to this point.

-- 
Darren Hart
Intel Open Source Technology Center

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Re: [PATCH 01/14] dell-laptop: extract SMBIOS-related code to a  separate module Darren Hart <dvhart@infradead.org> - 2016-02-09 18:00 +0100
  Re: [PATCH 01/14] dell-laptop: extract SMBIOS-related code to a separate module Pali Rohár <pali.rohar@gmail.com> - 2016-02-09 20:20 +0100
    Re: [PATCH 01/14] dell-laptop: extract SMBIOS-related code to a  separate module Darren Hart <dvhart@infradead.org> - 2016-02-11 00:10 +0100

csiph-web