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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.