Re: [PATCH 2.4] add SMBIOS information to /proc/smbios -- UPDATED

• Previous message: Andrew Morton: "Re: [PATCH] Fixes in 32 bit ioctl emulation code"
• Next in thread: Michael Brown: "Re: [PATCH 2.4] add SMBIOS information to /proc/smbios -- UPDATED"
• Reply: Michael Brown: "Re: [PATCH 2.4] add SMBIOS information to /proc/smbios -- UPDATED"
• Reply: Andi Kleen: "Re: [PATCH 2.4] add SMBIOS information to /proc/smbios -- UPDATED"
• Maybe reply: Lev Makhlis: "Re: [PATCH 2.4] add SMBIOS information to /proc/smbios -- UPDATED"
• Maybe reply: Marcelo Tosatti: "Re: [PATCH 2.4] add SMBIOS information to /proc/smbios -- UPDATED"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

To: Andi Kleen <ak@muc.de>
Date:	Fri, 30 Apr 2004 22:30:04 -0500

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

• Previous message: Andrew Morton: "Re: [PATCH] Fixes in 32 bit ioctl emulation code"
• Next in thread: Michael Brown: "Re: [PATCH 2.4] add SMBIOS information to /proc/smbios -- UPDATED"
• Reply: Michael Brown: "Re: [PATCH 2.4] add SMBIOS information to /proc/smbios -- UPDATED"
• Reply: Andi Kleen: "Re: [PATCH 2.4] add SMBIOS information to /proc/smbios -- UPDATED"
• Maybe reply: Lev Makhlis: "Re: [PATCH 2.4] add SMBIOS information to /proc/smbios -- UPDATED"
• Maybe reply: Marcelo Tosatti: "Re: [PATCH 2.4] add SMBIOS information to /proc/smbios -- UPDATED"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]