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: <20160209135846.GB7443@eudyptula.hq.kempniu.pl>
Date:	Tue, 9 Feb 2016 14:58:46 +0100
From:	Michał Kępień <kernel@...pniu.pl>
To:	Pali Rohár <pali.rohar@...il.com>
Cc:	Darren Hart <dvhart@...radead.org>,
	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

> > 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).

Pali, forgive me, but I fail to understand your last two sentences.
Currently, we don't have functions for allocating/freeing the SMBIOS
buffer as it is allocated in dell_init() (or dell_smbios_init() after
applying this patch series) and freed in dell_(smbios_)exit().

In your previous messages [1][2], you suggested that we could allocate a
separate SMBIOS buffer for each caller or copy input parameters from
caller-allocated memory into a module-wide SMBIOS buffer before
performing the SMBIOS request.  Did you just mean to remind Darren of
these ideas or did you have something else on your mind?  If the latter,
could you please try rephrasing the last two sentences of your message?

[1] http://www.spinics.net/lists/platform-driver-x86/msg08260.html
[2] http://www.spinics.net/lists/platform-driver-x86/msg08268.html

-- 
Best regards,
Michał Kępień