Message-ID: <1400143708.24633.39.camel@chaos.site>
Date:	Thu, 15 May 2014 10:48:28 +0200
From:	Jean Delvare <jdelvare@...e.de>
To:	Mike Waychison <mikew@...gle.com>
Cc:	Bjorn Helgaas <bhelgaas@...gle.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Purpose of dmi-sysfs kernel module

Hi Mike,

Le Wednesday 14 May 2014 à 15:51 -0700, Mike Waychison a écrit :
> On Wed, May 14, 2014 at 12:23 PM, Jean Delvare <jdelvare@...e.de> wrote:
> > Thanks for the explanation. But if access to /dev/mem was your only
> > concern, your solution seems somewhat overkill. You could have just
> > exposed the raw SMBIOS entry point and DMI table through sysfs, pretty
> > much like ACPI does, and leave the rest to dmidecode (or libsmbios.)
> > That would have avoided reimplementing part of dmidecode and creating
> > yet another interface to DMI data.
> 
> I tried to make dmi-sysfs be as dumb as possible, which is why the
> code doesn't try very hard to actually interpret the individual
> entries, and instead only exposes them as "raw" files.

In case I wasn't clear enough: my concern isn't that dmi-sysfs is too
dumb, but that it is doing too much.

>   The only
> "specialized" type (that actually decodes the entry in kernel-land) is
> type 15, as this entry provides a level of indirection to get at the
> system log (which is either elsewhere in raw /dev/mem memory, or only
> accessible behind IO ports).  Again, in this case, only the raw system
> event log is exposed and the kernel makes no attempt to parse this
> log, it only exposes the raw read-only bytes.

That's what I would expect the dmi-sysfs kernel driver to do for every
table or relevant I/O area: pass the data through to user-space and let
user-space decode it.

> > I'm not maintaining dmi-sysfs, I'm not even using it so far, so I don't
> > really care, but to be honest I am quite surprised that it was accepted
> > into the kernel.
> 
> Well, it solves some real problems for us while locking down userland
> access to /dev/mem and iopl.

I am not questioning the fact that it solves a real problem. I just
don't think it was the best way to solve it. And I feel a bit sad that
the point was not even raised on the dmidecode-devel list.

> I have had several folks ask me in the past as to why dmidecode
> doesn't work when these facilities are removed from userland, and
> dmi-sysfs has proven to be a workable alternative for most.  That
> said, dmidecode is the de facto method people use for getting at this
> data, and I have no intention on replacing it -- rather, I was hoping
> that at some point dmidecode could be updated to understand how to
> read the raw sysfs file in lieu of requiring superuser privileges, but
> I haven't had the opportunity or need to make this happen myself.

With the current implementation of dmi-sysfs, that would require a
significant amount of extra code in dmidecode, to
walk /sys/firmware/dmi/entries, parse all the files there and inject all
the pieces into the existing decoding loop. I'm not going to do that,
sorry.

Now if dmi-sysfs would simply export raw tables through sysfs as acpi
does, it would be truly trivial to hook dmidecode to it as a preferred
alternative to reading from /dev/mem. That, I would be happy to
implement in dmidecode.

-- 
Jean Delvare
SUSE L3 Support

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists