lkml.org 
[lkml]   [2002]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] export e820 table on x86

On Thu, 21 Nov 2002, Dave Hansen wrote:
> >
> > - why isn't the info in /proc/iomem good enough - ie wouldn't it be
> > better to just extend resource handling to 64 bit instead of
> > creating a new file.
>
> It looks good enough. The only irritating part is turning the "S3
> Inc. Trio 64 3D" or "ACPI Tables" back into the numberic e820 type.

Actually, those aren't part of the e820 map at all - Linux gets those from
doing PCI probing, since the e820 table does not itself tell _what_ the
resources are allocated for.

> What would you think of just adding another field to /proc/iomem which
> contains the e820 field type?

Actually, it's already there, to some degree. See the case statement in
register_memory() in arch/i386/kernel/setup.c, and see how all the e820
information percolates down from the e820 array into a simple
"request_resource()".

See also how we artificially only show 32-bit resources, because "struct
resource" uses "unsigned long". That's a design mistake, and it _should_
be "u64" (this actually could cause problems already on 64-bit PCI on
32-bit hosts, although it appears that nobody even tries to map devices
past the 4GB area anyway), but I've never had a test-case for fixing it
and seeing any difference.

In other words, I would suggest you fix that 64-bit issue, remove the
artificial limiting in setup.c, extend the "case" statement to cover any
cases you're interested in, and test it on something with >4GB of memory
to see that it works, and I'll be more than happy to take it.

Please?

Linus

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:31    [W:0.240 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site