netdev - Re: [lm-sensors] [PATCH 01/34] System Firmware Interface

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] [day] [month] [year] [list]

Date:	Mon, 25 Jul 2011 21:03:21 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	Prarit Bhargava <prarit@...hat.com>
Cc:	linux-kernel@...r.kernel.org, linux-ia64@...r.kernel.org,
	linux-pci@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	platform-driver-x86@...r.kernel.org, grant.likely@...retlab.ca,
	linux-ide@...r.kernel.org, linux-i2c@...r.kernel.org,
	device-drivers-devel@...ckfin.uclinux.org, abelay@....edu,
	eric.piel@...mplin-utc.net, x86@...nel.org,
	lm-sensors@...sensors.org, linux-acpi@...r.kernel.org,
	linux-input@...r.kernel.org, linux-media@...r.kernel.org,
	johnpol@....mipt.ru, linux-watchdog@...r.kernel.org,
	rtc-linux@...glegroups.com, dz@...ian.org,
	openipmi-developer@...ts.sourceforge.net,
	evel@...verdev.osuosl.org, netdev@...r.kernel.org,
	linux-usb@...r.kernel.org, rpurdie@...ys.net,
	linux-crypto@...r.kernel.org
Subject: Re: [lm-sensors] [PATCH 01/34] System Firmware Interface

On Mon, 18 Jul 2011 09:08:15 -0400, Prarit Bhargava wrote:
> This patch introduces a general System Firmware interface to the kernel, called
> sysfw.
> 
> Inlcluded in this interface is the ability to search a standard set of fields,
> sysfw_lookup().  The fields are currently based upon the x86 and ia64 SMBIOS
> fields but exapandable to fields that other arches may introduce.  Also
> included is  the ability to search and match against those fields, and run
> a callback function against the matches, sysfw_callback().
> 
> Modify module code to use sysfw instead of old DMI interface.

This is a HUGE patch set. You'd need to have a good reason for such a
big and intrusive change, yet I see no such reason explained. I
understand that we _can_ abstract system information interfaces, but
just because we can doesn't mean we have to. I would at least wait for
a second DMI-like interface to be widely implemented and support before
any attempt to abstract, otherwise your design is bound to be missing
the target. And even then, you'd still need to convince me that there
is a need for a unified interface to access both backends at once. I
would guess that you know what backend is present on a system when you
try to identify it.

At this point, I see the work needed to review your patches, the risk
of regressions due to the large size of the patch set, but I don't see
any immediate benefit. Thus I am not going to look into it at all,
sorry.

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html