lkml.org 
[lkml]   [2005]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Fastboot] Re: [PATCH] /proc/cpumem
From
Date
Dave Jones <davej@redhat.com> writes:

> On Wed, Feb 16, 2005 at 05:49:51PM +0900, Itsuro Oda wrote:
> > Hi, Eric and all
> >
> > Attached is an implementation of /proc/cpumem.
> > /proc/cpumem shows the valid physical memory ranges.
> >
> > * i386 and x86_64
> > * implement valid_phys_addr_range() and use it.
> > (the first argument of the i386 version is little uncomfortable.)
> > * /dev/mem of the i386 version should be mofified. but not yet.
> >
> > example: amd64 8GB Mem
> > # cat /proc/cpumem
> > 0000000000000000 000000000009b800
> > 0000000000100000 00000000fbe70000
> > 0000000100000000 0000000100000000
> > #
> > start address and size. hex digit.
> >
> > Any comments, recomendations and suggestions are welcom.
>
> It may make more sense to export the entire e820 (or similar)
> bios memory tables. Probably better off in sysfs than adding
> more cruft to procfs too.

Agreed. In practice we actually do this already with /proc/iomem.
Except that we truncate everything above 4GB, and we allow the
map to get mangled with mem=xxx options.

I brought up the idea of a /proc/cpumem by analogy because on platforms
that have an iommu and memory is in a distinct address space
there have been complaints that /proc/iomem just won't work. But it
is simple enough to do something that is just for the cpu's memory.

As for how to do this cleanly this looks like the start of that discussion.

Eric
-
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 14:10    [from the cache]
©2003-2011 Jasper Spaans