Itsuro Oda <[EMAIL PROTECTED]> writes:
> I see. I would like to contribute as possible I can.
Pick some piece you that have an affinity for and work on it.
Problems are best solved by those who see them and by those who care :)
I believe Vivek Goyal is currently working on the remaining user spa
Hi,
On 17 Feb 2005 02:55:31 -0700
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
> My role in this is that of maintainer and architect. On a practical
> level I gain nothing from a working crash-dump/kexec-on-panic
> implementation except it stops being a gating factor for the rest
> of the kexec
Dave Jones <[EMAIL PROTECTED]> 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_ad
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 i
Itsuro Oda <[EMAIL PROTECTED]> writes:
> Hi Eric,
>
> > The lack of a type field looses a fair amount of functionality compared
> > to /proc/iomem. In particular you can't see where the ACPI data is.
>
> Hmm, restricting System RAM only may be too pessimistic.
> (One of motivations of this work
Hi,
> I thought efi related data structures are of type __initdata and will be gone
> after initilization. (efi.c)
oops. certainly.
and, devmem_is_allowed does same mistake :-)
(I don't know who made it.)
Thanks.
--
Itsuro ODA <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line
Hi,
On Wed, 2005-02-16 at 14:19, Itsuro Oda wrote:
>
> BTW, does not kexec/kdump run on 2.6.11-rc3-mm2 ?
> How do I get and examine the latest kexec/kdump ?
Currently kdump is broken. I am working on Elf Header generation part in
kexec-tools. Next week I should be able to post the initial patch
Hi Eric,
> The lack of a type field looses a fair amount of functionality compared
> to /proc/iomem. In particular you can't see where the ACPI data is.
Hmm, restricting System RAM only may be too pessimistic.
(One of motivations of this work is for using /dev/mem safely.
"dd if=/dev/mem of=xxx
hi,
> + while (addr < end) {
> + if (valid_phys_addr_range(addr, &size)) {
> + if (!found) {
> + found = 1;
> + p->addr = addr;
> + p->size = size;
> + } else
Itsuro Oda <[EMAIL PROTECTED]> writes:
> Hi, Eric and all
>
> Attached is an implementation of /proc/cpumem.
> /proc/cpumem shows the valid physical memory ranges.
Interesting. My imagination when I proposed this
was something based on struct resource that works
like /proc/iomem on x86 but can
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 mofif
11 matches
Mail list logo
