/dev/oldmem provides the interface for us to access the "old memory" in
the dump-capture kernel. Unfortunately, no one actually uses this interface.
And this interface could actually cause some real problems if used on ia64
where the cached/uncached accesses are mixed. See the discussion from
the link: https://lkml.org/lkml/2013/4/12/386.
So Eric suggested that we should remove /dev/oldmem as an unused piece of
code.
Besides, we used a global variable saved_max_pfn to let the capture kernel
know the amount of memory that the previous kernel used. And for almost all
architectures (except x86. In x86, saved_max_pfn is used by detect_calgary()),
the only user of this variable is the read_oldmem interface of /dev/oldmem, so
also remove the setting for saved_max_pfn in those architectures.
Zhang Yanfei (7):
/dev/oldmem: Remove this interface
Documentation/devices.txt: Remove /dev/oldmem description
Documentation/kdump/kdump.txt: Remove /dev/oldmem description
mips: Remove savemaxmem parameter setup
powerpc: Remove savemaxmem parameter setup
ia64: Remove setting for saved_max_pfn
s390: Remove setting for saved_max_pfn
Documentation/devices.txt | 2 -
Documentation/kdump/kdump.txt | 31 +++++--------------------
arch/ia64/kernel/efi.c | 5 ----
arch/mips/kernel/crash_dump.c | 10 --------
arch/powerpc/kernel/crash_dump.c | 10 --------
arch/s390/kernel/setup.c | 4 ---
drivers/char/mem.c | 47 --------------------------------------
7 files changed, 6 insertions(+), 103 deletions(-)
From: Zhang Yanfei <[email protected]>
/dev/oldmem provides the interface for us to access the "old memory" in
the dump-capture kernel. Unfortunately, no one actually uses this interface.
And this interface could actually cause some real problems if used on ia64
where the cached/uncached accesses are mixed. See the discussion from
the link: https://lkml.org/lkml/2013/4/12/386.
So Eric suggested that we should remove /dev/oldmem as an unused piece of
code.
Suggested-by: "Eric W. Biederman" <[email protected]>
Signed-off-by: Zhang Yanfei <[email protected]>
Cc: Vivek Goyal <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: Andrew Morton <[email protected]>
---
drivers/char/mem.c | 47 -----------------------------------------------
1 files changed, 0 insertions(+), 47 deletions(-)
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 1ccbe94..bbe8ab4 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -21,7 +21,6 @@
#include <linux/ptrace.h>
#include <linux/device.h>
#include <linux/highmem.h>
-#include <linux/crash_dump.h>
#include <linux/backing-dev.h>
#include <linux/bootmem.h>
#include <linux/splice.h>
@@ -357,40 +356,6 @@ static int mmap_kmem(struct file *file, struct vm_area_struct *vma)
}
#endif
-#ifdef CONFIG_CRASH_DUMP
-/*
- * Read memory corresponding to the old kernel.
- */
-static ssize_t read_oldmem(struct file *file, char __user *buf,
- size_t count, loff_t *ppos)
-{
- unsigned long pfn, offset;
- size_t read = 0, csize;
- int rc = 0;
-
- while (count) {
- pfn = *ppos / PAGE_SIZE;
- if (pfn > saved_max_pfn)
- return read;
-
- offset = (unsigned long)(*ppos % PAGE_SIZE);
- if (count > PAGE_SIZE - offset)
- csize = PAGE_SIZE - offset;
- else
- csize = count;
-
- rc = copy_oldmem_page(pfn, buf, csize, offset, 1);
- if (rc < 0)
- return rc;
- buf += csize;
- *ppos += csize;
- read += csize;
- count -= csize;
- }
- return read;
-}
-#endif
-
#ifdef CONFIG_DEVKMEM
/*
* This function reads the *virtual* memory as seen by the kernel.
@@ -772,7 +737,6 @@ static int open_port(struct inode *inode, struct file *filp)
#define aio_write_zero aio_write_null
#define open_mem open_port
#define open_kmem open_mem
-#define open_oldmem open_mem
static const struct file_operations mem_fops = {
.llseek = memory_lseek,
@@ -837,14 +801,6 @@ static const struct file_operations full_fops = {
.write = write_full,
};
-#ifdef CONFIG_CRASH_DUMP
-static const struct file_operations oldmem_fops = {
- .read = read_oldmem,
- .open = open_oldmem,
- .llseek = default_llseek,
-};
-#endif
-
static const struct memdev {
const char *name;
umode_t mode;
@@ -866,9 +822,6 @@ static const struct memdev {
#ifdef CONFIG_PRINTK
[11] = { "kmsg", 0644, &kmsg_fops, NULL },
#endif
-#ifdef CONFIG_CRASH_DUMP
- [12] = { "oldmem", 0, &oldmem_fops, NULL },
-#endif
};
static int memory_open(struct inode *inode, struct file *filp)
--
1.7.1
From: Zhang Yanfei <[email protected]>
Signed-off-by: Zhang Yanfei <[email protected]>
Cc: Dave Jones <[email protected]>
---
Documentation/devices.txt | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/Documentation/devices.txt b/Documentation/devices.txt
index 08f01e7..4f85739 100644
--- a/Documentation/devices.txt
+++ b/Documentation/devices.txt
@@ -100,8 +100,6 @@ Your cooperation is appreciated.
10 = /dev/aio Asynchronous I/O notification interface
11 = /dev/kmsg Writes to this come out as printk's, reads
export the buffered printk records.
- 12 = /dev/oldmem Used by crashdump kernels to access
- the memory of the kernel that crashed.
1 block RAM disk
0 = /dev/ram0 First RAM disk
--
1.7.1
From: Zhang Yanfei <[email protected]>
Signed-off-by: Zhang Yanfei <[email protected]>
Cc: Vivek Goyal <[email protected]>
---
Documentation/kdump/kdump.txt | 31 ++++++-------------------------
1 files changed, 6 insertions(+), 25 deletions(-)
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 9c7fd98..bec123e 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -47,19 +47,12 @@ parameter. Optionally the size of the ELF header can also be passed
when using the elfcorehdr=[size[KMG]@]offset[KMG] syntax.
-With the dump-capture kernel, you can access the memory image, or "old
-memory," in two ways:
-
-- Through a /dev/oldmem device interface. A capture utility can read the
- device file and write out the memory in raw format. This is a raw dump
- of memory. Analysis and capture tools must be intelligent enough to
- determine where to look for the right information.
-
-- Through /proc/vmcore. This exports the dump as an ELF-format file that
- you can write out using file copy commands such as cp or scp. Further,
- you can use analysis tools such as the GNU Debugger (GDB) and the Crash
- tool to debug the dump file. This method ensures that the dump pages are
- correctly ordered.
+With the dump-capture kernel, you can access the memory image through
+/proc/vmcore. This exports the dump as an ELF-format file that you can
+write out using file copy commands such as cp or scp. Further, you can
+use analysis tools such as the GNU Debugger (GDB) and the Crash tool to
+debug the dump file. This method ensures that the dump pages are correctly
+ordered.
Setup and Installation
@@ -423,18 +416,6 @@ the following command:
cp /proc/vmcore <dump-file>
-You can also access dumped memory as a /dev/oldmem device for a linear
-and raw view. To create the device, use the following command:
-
- mknod /dev/oldmem c 1 12
-
-Use the dd command with suitable options for count, bs, and skip to
-access specific portions of the dump.
-
-To see the entire memory, use the following command:
-
- dd if=/dev/oldmem of=oldmem.001
-
Analysis
========
--
1.7.1
From: Zhang Yanfei <[email protected]>
saved_max_pfn is used to know the amount of memory that the previous
kernel used. And for powerpc, we set saved_max_pfn by passing the
kernel commandline parameter "savemaxmem=".
The only user of saved_max_pfn in mips is read_oldmem interface.
Since we have removed read_oldmem, so we don't need this parameter
anymore.
Signed-off-by: Zhang Yanfei <[email protected]>
Cc: Ralf Baechle <[email protected]>
---
arch/mips/kernel/crash_dump.c | 10 ----------
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/arch/mips/kernel/crash_dump.c b/arch/mips/kernel/crash_dump.c
index 3be9e7b..f291cf9 100644
--- a/arch/mips/kernel/crash_dump.c
+++ b/arch/mips/kernel/crash_dump.c
@@ -4,16 +4,6 @@
#include <asm/uaccess.h>
#include <linux/slab.h>
-static int __init parse_savemaxmem(char *p)
-{
- if (p)
- saved_max_pfn = (memparse(p, &p) >> PAGE_SHIFT) - 1;
-
- return 1;
-}
-__setup("savemaxmem=", parse_savemaxmem);
-
-
static void *kdump_buf_page;
/**
--
1.7.1
From: Zhang Yanfei <[email protected]>
saved_max_pfn is used to know the amount of memory that the previous
kernel used. And for powerpc, we set saved_max_pfn by passing the
kernel commandline parameter "savemaxmem=".
The only user of saved_max_pfn in powerpc is read_oldmem interface.
Since we have removed read_oldmem, we don't need this parameter anymore.
Signed-off-by: Zhang Yanfei <[email protected]>
Cc: Benjamin Herrenschmidt <[email protected]>
Cc: Paul Mackerras <[email protected]>
---
arch/powerpc/kernel/crash_dump.c | 10 ----------
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/crash_dump.c b/arch/powerpc/kernel/crash_dump.c
index 9ec3fe1..779a78c 100644
--- a/arch/powerpc/kernel/crash_dump.c
+++ b/arch/powerpc/kernel/crash_dump.c
@@ -69,16 +69,6 @@ void __init setup_kdump_trampoline(void)
}
#endif /* CONFIG_NONSTATIC_KERNEL */
-static int __init parse_savemaxmem(char *p)
-{
- if (p)
- saved_max_pfn = (memparse(p, &p) >> PAGE_SHIFT) - 1;
-
- return 1;
-}
-__setup("savemaxmem=", parse_savemaxmem);
-
-
static size_t copy_oldmem_vaddr(void *vaddr, char *buf, size_t csize,
unsigned long offset, int userbuf)
{
--
1.7.1
From: Zhang Yanfei <[email protected]>
The only user of saved_max_pfn in ia64 is read_oldmem interface but we
have removed that interface, so saved_max_pfn is now unneeded in ia64,
and we needn't set it anymore.
Signed-off-by: Zhang Yanfei <[email protected]>
Cc: Matt Fleming <[email protected]>
Cc: Tony Luck <[email protected]>
Cc: Fenghua Yu <[email protected]>
---
arch/ia64/kernel/efi.c | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
index f034563..51bce59 100644
--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -1116,11 +1116,6 @@ efi_memmap_init(u64 *s, u64 *e)
if (!is_memory_available(md))
continue;
-#ifdef CONFIG_CRASH_DUMP
- /* saved_max_pfn should ignore max_addr= command line arg */
- if (saved_max_pfn < (efi_md_end(md) >> PAGE_SHIFT))
- saved_max_pfn = (efi_md_end(md) >> PAGE_SHIFT);
-#endif
/*
* Round ends inward to granule boundaries
* Give trimmings to uncached allocator
--
1.7.1
From: Zhang Yanfei <[email protected]>
The only user of saved_max_pfn in s390 is read_oldmem interface but we
have removed that interface, so saved_max_pfn is now unneeded in s390,
and we needn't set it anymore.
Signed-off-by: Zhang Yanfei <[email protected]>
Cc: Martin Schwidefsky <[email protected]>
Cc: Heiko Carstens <[email protected]>
Cc: Michael Holzheu <[email protected]>
---
arch/s390/kernel/setup.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index 0a49095..497451e 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -719,10 +719,6 @@ static void reserve_oldmem(void)
}
create_mem_hole(memory_chunk, OLDMEM_BASE, OLDMEM_SIZE);
create_mem_hole(memory_chunk, OLDMEM_SIZE, real_size - OLDMEM_SIZE);
- if (OLDMEM_BASE + OLDMEM_SIZE == real_size)
- saved_max_pfn = PFN_DOWN(OLDMEM_BASE) - 1;
- else
- saved_max_pfn = PFN_DOWN(real_size) - 1;
#endif
}
--
1.7.1
Awesome!
Zhang Yanfei <[email protected]> wrote:
>/dev/oldmem provides the interface for us to access the "old memory" in
>the dump-capture kernel. Unfortunately, no one actually uses this
>interface.
>
>And this interface could actually cause some real problems if used on
>ia64
>where the cached/uncached accesses are mixed. See the discussion from
>the link: https://lkml.org/lkml/2013/4/12/386.
>
>So Eric suggested that we should remove /dev/oldmem as an unused piece
>of
>code.
>
>Besides, we used a global variable saved_max_pfn to let the capture
>kernel
>know the amount of memory that the previous kernel used. And for almost
>all
>architectures (except x86. In x86, saved_max_pfn is used by
>detect_calgary()),
>the only user of this variable is the read_oldmem interface of
>/dev/oldmem, so
>also remove the setting for saved_max_pfn in those architectures.
>
>Zhang Yanfei (7):
> /dev/oldmem: Remove this interface
> Documentation/devices.txt: Remove /dev/oldmem description
> Documentation/kdump/kdump.txt: Remove /dev/oldmem description
> mips: Remove savemaxmem parameter setup
> powerpc: Remove savemaxmem parameter setup
> ia64: Remove setting for saved_max_pfn
> s390: Remove setting for saved_max_pfn
>
> Documentation/devices.txt | 2 -
> Documentation/kdump/kdump.txt | 31 +++++--------------------
> arch/ia64/kernel/efi.c | 5 ----
> arch/mips/kernel/crash_dump.c | 10 --------
> arch/powerpc/kernel/crash_dump.c | 10 --------
> arch/s390/kernel/setup.c | 4 ---
>drivers/char/mem.c | 47
>--------------------------------------
> 7 files changed, 6 insertions(+), 103 deletions(-)
--
Sent from my mobile phone. Please excuse brevity and lack of formatting.
Zhang Yanfei <[email protected]> writes:
> From: Zhang Yanfei <[email protected]>
Won't we want to keep this reservation around to so that this number
doesn't get reused, and cause people confusion when
upgrading/downgrading kernels?
> Signed-off-by: Zhang Yanfei <[email protected]>
> Cc: Dave Jones <[email protected]>
> ---
> Documentation/devices.txt | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devices.txt b/Documentation/devices.txt
> index 08f01e7..4f85739 100644
> --- a/Documentation/devices.txt
> +++ b/Documentation/devices.txt
> @@ -100,8 +100,6 @@ Your cooperation is appreciated.
> 10 = /dev/aio Asynchronous I/O notification interface
> 11 = /dev/kmsg Writes to this come out as printk's, reads
> export the buffered printk records.
> - 12 = /dev/oldmem Used by crashdump kernels to access
> - the memory of the kernel that crashed.
>
> 1 block RAM disk
> 0 = /dev/ram0 First RAM disk
Zhang Yanfei <[email protected]> writes:
> /dev/oldmem provides the interface for us to access the "old memory" in
> the dump-capture kernel. Unfortunately, no one actually uses this interface.
>
> And this interface could actually cause some real problems if used on ia64
> where the cached/uncached accesses are mixed. See the discussion from
> the link: https://lkml.org/lkml/2013/4/12/386.
>
> So Eric suggested that we should remove /dev/oldmem as an unused piece of
> code.
>
> Besides, we used a global variable saved_max_pfn to let the capture kernel
> know the amount of memory that the previous kernel used. And for almost all
> architectures (except x86. In x86, saved_max_pfn is used by detect_calgary()),
> the only user of this variable is the read_oldmem interface of /dev/oldmem, so
> also remove the setting for saved_max_pfn in those architectures.
Except for the devices.txt update.
Acked-by: "Eric W. Biederman" <[email protected]>
> Zhang Yanfei (7):
> /dev/oldmem: Remove this interface
> Documentation/devices.txt: Remove /dev/oldmem description
> Documentation/kdump/kdump.txt: Remove /dev/oldmem description
> mips: Remove savemaxmem parameter setup
> powerpc: Remove savemaxmem parameter setup
> ia64: Remove setting for saved_max_pfn
> s390: Remove setting for saved_max_pfn
>
> Documentation/devices.txt | 2 -
> Documentation/kdump/kdump.txt | 31 +++++--------------------
> arch/ia64/kernel/efi.c | 5 ----
> arch/mips/kernel/crash_dump.c | 10 --------
> arch/powerpc/kernel/crash_dump.c | 10 --------
> arch/s390/kernel/setup.c | 4 ---
> drivers/char/mem.c | 47 --------------------------------------
> 7 files changed, 6 insertions(+), 103 deletions(-)
于 2013年05月26日 07:20, Eric W. Biederman 写道:
> Zhang Yanfei <[email protected]> writes:
>
>> From: Zhang Yanfei <[email protected]>
>
> Won't we want to keep this reservation around to so that this number
> doesn't get reused, and cause people confusion when
> upgrading/downgrading kernels?
Ah, yes. I will just keep this and add a note to make people know that
it is removed in the next version.
Thanks
Zhang
>
>> Signed-off-by: Zhang Yanfei <[email protected]>
>> Cc: Dave Jones <[email protected]>
>> ---
>> Documentation/devices.txt | 2 --
>> 1 files changed, 0 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devices.txt b/Documentation/devices.txt
>> index 08f01e7..4f85739 100644
>> --- a/Documentation/devices.txt
>> +++ b/Documentation/devices.txt
>> @@ -100,8 +100,6 @@ Your cooperation is appreciated.
>> 10 = /dev/aio Asynchronous I/O notification interface
>> 11 = /dev/kmsg Writes to this come out as printk's, reads
>> export the buffered printk records.
>> - 12 = /dev/oldmem Used by crashdump kernels to access
>> - the memory of the kernel that crashed.
>>
>> 1 block RAM disk
>> 0 = /dev/ram0 First RAM disk
(2013/05/26 9:58), Zhang Yanfei wrote:
> 于 2013年05月26日 07:20, Eric W. Biederman 写道:
>> Zhang Yanfei <[email protected]> writes:
>>
>>> From: Zhang Yanfei <[email protected]>
>>
>> Won't we want to keep this reservation around to so that this number
>> doesn't get reused, and cause people confusion when
>> upgrading/downgrading kernels?
>
> Ah, yes. I will just keep this and add a note to make people know that
> it is removed in the next version.
>
It looks enough writing "obsolete" according to the other parts of the same file.
--
Thanks.
HATAYAMA, Daisuke
于 2013年05月27日 09:27, HATAYAMA Daisuke 写道:
> (2013/05/26 9:58), Zhang Yanfei wrote:
>> 于 2013年05月26日 07:20, Eric W. Biederman 写道:
>>> Zhang Yanfei <[email protected]> writes:
>>>
>>>> From: Zhang Yanfei <[email protected]>
>>>
>>> Won't we want to keep this reservation around to so that this number
>>> doesn't get reused, and cause people confusion when
>>> upgrading/downgrading kernels?
>>
>> Ah, yes. I will just keep this and add a note to make people know that
>> it is removed in the next version.
>>
>
> It looks enough writing "obsolete" according to the other parts of the same file.
>
I've sent the v2 version and actually did what you said.
Thanks
Zhang
On Sat, May 25, 2013 at 04:25:21PM -0700, Eric W. Biederman wrote:
> Zhang Yanfei <[email protected]> writes:
>
> > /dev/oldmem provides the interface for us to access the "old memory" in
> > the dump-capture kernel. Unfortunately, no one actually uses this interface.
> >
> > And this interface could actually cause some real problems if used on ia64
> > where the cached/uncached accesses are mixed. See the discussion from
> > the link: https://lkml.org/lkml/2013/4/12/386.
> >
> > So Eric suggested that we should remove /dev/oldmem as an unused piece of
> > code.
> >
> > Besides, we used a global variable saved_max_pfn to let the capture kernel
> > know the amount of memory that the previous kernel used. And for almost all
> > architectures (except x86. In x86, saved_max_pfn is used by detect_calgary()),
> > the only user of this variable is the read_oldmem interface of /dev/oldmem, so
> > also remove the setting for saved_max_pfn in those architectures.
>
> Except for the devices.txt update.
>
> Acked-by: "Eric W. Biederman" <[email protected]>
Eric,
Should we schedule the removal of this interface after 1-2 releases
and give a warning once if anybody opens /dev/oldmem and tell them
to use /proc/vmcore instead?
I am kind of inclined towards warning approarch. If there is any xyz
/dev/oldmem user in the wild out there, he/she atleast gets a chance to
migrate to /proc/vmcore.
Thanks
Vivek
On 05/28/2013 07:37 AM, Vivek Goyal wrote:
>
> Eric,
>
> Should we schedule the removal of this interface after 1-2 releases
> and give a warning once if anybody opens /dev/oldmem and tell them
> to use /proc/vmcore instead?
>
> I am kind of inclined towards warning approarch. If there is any xyz
> /dev/oldmem user in the wild out there, he/she atleast gets a chance to
> migrate to /proc/vmcore.
>
This has been discussed ad nauseam at the Kernel Summit. It doesn't work.
-hpa
>
>Should we schedule the removal of this interface after 1-2 releases
>and give a warning once if anybody opens /dev/oldmem and tell them
>to use /proc/vmcore instead?
How can anyone use /dev/oldmem correctly? To the best of
my knowledge there are no parsers of the ELF header passed
by /sbin/kexec in userspace.
If there is anyone who cares they can complain and we can
revert the removal. All of the evidence is that everyone uses
/proc/vmcore.
>I am kind of inclined towards warning approarch. If there is any xyz
>/dev/oldmem user in the wild out there, he/she atleast gets a chance to
>migrate to /proc/vmcore.
If there is a user out there that does not choose to participate
in the community, or pay someone to participate on their
behalf, it saddens me but I don't care.
All someone has to do is to keep a weather eye on the kexec
mailing list, the linux kernel mailing list or simply run a test
kernel, and tell us that they use /dev/oldmem. That is grounds
under the no regression rule for a revert.
At a practical level a user who does not care will likely be using
a frozen kernel and won't notice until they finally decide to
upgrade their kernel, in several years time.
I don't think we should carry an apparently dead interface
around for the next five years on the off chance someone uses
it. Especially with no users and no one who cares we won't
maintain the interface properly and it will bit rot and be
broken.
Which means if there is someone using /dev/oldmem we have
a choice of what to do in 5 years time when someone notices.
- Field a bug report about someones kdump implementation
acting weird.
- Deal with a report of someones kdump implementation not
working because /dev/oldmem is gone.
With /dev/oldmem gone at least we will be able to get to the root cause of the problem. -ENODEV.
Which is a long way of saying this is the time for anyone who uses /dev/oldmem to speak now or forever hold their piece.
Eric
On Tue, May 28, 2013 at 12:00:45PM -0700, Eric W. Biederman wrote:
[..]
> How can anyone use /dev/oldmem correctly? To the best of
> my knowledge there are no parsers of the ELF header passed
> by /sbin/kexec in userspace.
>
> If there is anyone who cares they can complain and we can
> revert the removal. All of the evidence is that everyone uses
> /proc/vmcore.
>
Ok, that's fine. Given the fact that none of us has ever encountered
/dev/oldmem user, it is reasonably safe to remove it.
Thanks
Vivek
On Tue, 28 May 2013 08:11:34 -0700 "H. Peter Anvin" <[email protected]> wrote:
> On 05/28/2013 07:37 AM, Vivek Goyal wrote:
> >
> > Eric,
> >
> > Should we schedule the removal of this interface after 1-2 releases
> > and give a warning once if anybody opens /dev/oldmem and tell them
> > to use /proc/vmcore instead?
> >
> > I am kind of inclined towards warning approarch. If there is any xyz
> > /dev/oldmem user in the wild out there, he/she atleast gets a chance to
> > migrate to /proc/vmcore.
> >
>
> This has been discussed ad nauseam at the Kernel Summit. It doesn't work.
>
Who said that and what was their evidence? Giving users (especially
the more technical ones) several months warning is eminently sensible.
Although it doesn't appear to be necessary in this case.
On Mon, 27 May 2013 09:27:42 +0800 Zhang Yanfei <[email protected]> wrote:
> ___ 2013___05___27___ 09:27, HATAYAMA Daisuke ______:
> > (2013/05/26 9:58), Zhang Yanfei wrote:
> >> ___ 2013___05___26___ 07:20, Eric W. Biederman ______:
> >>> Zhang Yanfei <[email protected]> writes:
> >>>
> >>>> From: Zhang Yanfei <[email protected]>
> >>>
> >>> Won't we want to keep this reservation around to so that this number
> >>> doesn't get reused, and cause people confusion when
> >>> upgrading/downgrading kernels?
> >>
> >> Ah, yes. I will just keep this and add a note to make people know that
> >> it is removed in the next version.
> >>
> >
> > It looks enough writing "obsolete" according to the other parts of the same file.
> >
>
> I've sent the v2 version and actually did what you said.
I can't find any v2 version of this patchset.
I did this:
--- a/Documentation/devices.txt~dev-oldmem-remove-the-interface-fix
+++ a/Documentation/devices.txt
@@ -102,6 +102,7 @@ Your cooperation is appreciated.
export the buffered printk records.
12 = /dev/oldmem Used by crashdump kernels to access
the memory of the kernel that crashed.
+ (obsolete)
1 block RAM disk
0 = /dev/ram0 First RAM disk
_
On 05/30/2013 06:20 AM, Andrew Morton wrote:
> On Mon, 27 May 2013 09:27:42 +0800 Zhang Yanfei <[email protected]> wrote:
>
snip
>>
>> I've sent the v2 version and actually did what you said.
>
> I can't find any v2 version of this patchset.
>
> I did this:
>
> --- a/Documentation/devices.txt~dev-oldmem-remove-the-interface-fix
> +++ a/Documentation/devices.txt
> @@ -102,6 +102,7 @@ Your cooperation is appreciated.
> export the buffered printk records.
> 12 = /dev/oldmem Used by crashdump kernels to access
> the memory of the kernel that crashed.
> + (obsolete)
>
> 1 block RAM disk
> 0 = /dev/ram0 First RAM disk
> _
>
>
v1 is the same with v2 except this patch. I attach it below:
-----------------------------------
>From d2f7baf2aba86069f941f32669a22dbd99082614 Mon Sep 17 00:00:00 2001
From: Zhang Yanfei <[email protected]>
Date: Wed, 29 May 2013 15:44:09 +0800
Subject: [PATCH] Documentation/devices.txt: Mark /dev/oldmem obsolete
Signed-off-by: Zhang Yanfei <[email protected]>
---
Documentation/devices.txt | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/Documentation/devices.txt b/Documentation/devices.txt
index 08f01e7..315455a 100644
--- a/Documentation/devices.txt
+++ b/Documentation/devices.txt
@@ -100,8 +100,7 @@ Your cooperation is appreciated.
10 = /dev/aio Asynchronous I/O notification interface
11 = /dev/kmsg Writes to this come out as printk's, reads
export the buffered printk records.
- 12 = /dev/oldmem Used by crashdump kernels to access
- the memory of the kernel that crashed.
+ 12 = /dev/oldmem OBSOLETE - replaced by /proc/vmcore
1 block RAM disk
0 = /dev/ram0 First RAM disk
--
1.7.1