Messages in this thread | | | Date | Thu, 21 Nov 2002 16:04:22 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [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/
| |