From: Michael Brown <mebrown@michaels-house.net>
To: Andi Kleen <ak@muc.de>
Cc: linux-kernel@vger.kernel.org, marcelo.tosatti@cyclades.com
Subject: Re: [PATCH 2.4] add SMBIOS information to /proc/smbios -- UPDATED
Date: Fri, 30 Apr 2004 22:30:04 -0500 [thread overview]
Message-ID: <1083382204.1203.2971.camel@debian> (raw)
In-Reply-To: <m3r7u59sok.fsf@averell.firstfloor.org>
On Fri, 2004-04-30 at 14:22, Andi Kleen wrote:
> Michael Brown <mebrown@michaels-house.net> writes:
>
> > Below is an updated patch to add SMBIOS information to /proc/smbios.
> > Updates have been made per Al's previous comments. Please apply.
>
> What is this good for? There are tools to read this from
> /dev/mem; and that is fine because the information is static.
> There is no reason to bloat the kernel with this.
As I mentioned in my first posting of this to l-k, there are three
reasons why this driver is necessary:
-- This information is, in the very near future, _not_ going to be
static anymore. There will be systems that update the information in
dynamically during SMIs.
-- SMBIOS consists of two things, the table entry point and the table
itself. The table entry point is always in 0xF0000 - 0xFFFFF.
Traditionally, the actual table has been here as well. BIOS is running
out of space here and future systems are moving this information to high
memory. /dev/mem will not allow access to memory above top of system
RAM.
-- Red Hat has a /dev/mem patch in their tree that restricts access to
RAM above 1MB.
Because of all of these reasons, we feel it is a good thing to have a
stable method to get to the SMBIOS information that will work into the
future. Our userspace libs will try to use this driver to access SMBIOS,
but fall back to /dev/mem if this driver is not available. (with the
caveat that nothing will work if table >1MB and this driver not
present.)
As for the "bloat" argument: this driver is about the most trivial
driver I can conceive of that does useful work. It is 250 raw lines of
code, comparable in size to /proc/meminfo or /proc/cpuinfo.
This 250 line driver allows us to move a few thousand lines of code from
Dell's current, proprietary systems management driver into userspace. If
this approach is accepted, I am pushing to work on opening up other
pieces of Dell's current proprietary drivers. This work is a
proof-of-concept to management that this approach can work.
--
Michael
next prev parent reply other threads:[~2004-05-01 3:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1QvX0-A4-29@gated-at.bofh.it>
2004-04-30 19:22 ` [PATCH 2.4] add SMBIOS information to /proc/smbios -- UPDATED Andi Kleen
2004-05-01 3:30 ` Michael Brown [this message]
2004-05-01 3:43 ` Michael Brown
2004-05-01 15:01 ` Andi Kleen
2004-05-03 23:49 Michael_E_Brown
-- strict thread matches above, loose matches on Subject: below --
2004-05-01 21:00 Lev Makhlis
2004-05-01 21:20 ` Andi Kleen
2004-04-30 2:21 Michael Brown
2004-04-30 3:34 ` viro
2004-04-30 4:37 ` Michael Brown
2004-05-03 23:40 ` Marcelo Tosatti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1083382204.1203.2971.camel@debian \
--to=mebrown@michaels-house.net \
--cc=ak@muc.de \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.tosatti@cyclades.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox