[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGTjWtAjfzr=7K_0k=MKRXTxiWDSGOOYrzY0tA-7z=BpLVM-gA@mail.gmail.com>
Date: Wed, 14 May 2014 08:52:36 -0700
From: Mike Waychison <mikew@...gle.com>
To: Jean Delvare <jdelvare@...e.de>
Cc: Bjorn Helgaas <bhelgaas@...gle.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Purpose of dmi-sysfs kernel module
Hi Jean,
On Wed, May 14, 2014 at 2:23 AM, Jean Delvare <jdelvare@...e.de> wrote:
> Hi Mike, Bjorn,
>
> Sorry for joining the party a little late but I am just discovering the
> dmi-sysfs kernel module. I have to admit that I am very curious about
> why it was needed. What does it let you achieve that you couldn't
> already do with dmidecode [1]?
The downside to using dmidecode is that (at least at the time), it
involved requiring giving access to /dev/mem to the binary so that it
could grub around in raw memory looking for the records. dmi-sysfs
provides an alternative that allows for kernel-parsed entries to be
exposed to userland without having to expose /dev/mem and raw IO which
is insecure.
> I read on LWM [2] that you were mostly interested in type 15 records,
> to gain access to the System Event Log information. Well, "dmidecode -t
> 15" does exactly that. It may be a bit late now but if anything is
> missing from dmidecode, I would rather add it there than implement a
> separate solution.
>
> [1] http://www.nongnu.org/dmidecode/
> [2] http://lwn.net/Articles/429427/
>
> Thanks,
> --
> 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