I would like to reserve a particular page of physical memory when
the kernel boots. By reserving I mean that no one else gets to read
from it or write to it: it is mine. Any suggestions for the best way
to go about this with a 2.5 kernel?
Thanks,
Duncan.
On Tue, 3 Dec 2002, Duncan Sands wrote:
> I would like to reserve a particular page of physical memory when
> the kernel boots. By reserving I mean that no one else gets to read
> from it or write to it: it is mine. Any suggestions for the best way
> to go about this with a 2.5 kernel?
>
> Thanks,
>
> Duncan.
If you need a certain page reserved at boot-time you are out-of-luck.
You can tell the kernel (using mem=xxx on the boot command line) that
you have somewhat less memory than you do and then you can write a
module that accesses the other memory that the kernel doesn't use.
If you just want to make sure that your module owns a particular
page that nobody else uses, just use ioremap() in your module to
allocate a particular address. Those page(s) are now owned by
your module and will never be paged. You can access those pages
from user-space by providing some connectivity in your module
(like read()/write()/ioctl()).
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Bush : The Fourth Reich of America
On Tue, 2002-12-03 at 21:11, Richard B. Johnson wrote:
> If you need a certain page reserved at boot-time you are out-of-luck.
Wrong - you can specify the precise memory map of a box as well as use
mem= to set the top of used memory. Its a painful way of marking a page
and it only works for a page the kernel isnt loaded into.
> If you need a certain page reserved at boot-time you are out-of-luck.
I don't mind modifying the kernel.
Duncan.
On Tue, 2002-12-03 at 12:52, Duncan Sands wrote:
> > If you need a certain page reserved at boot-time you are out-of-luck.
>
> I don't mind modifying the kernel.
Makes it easier to mark pages - look at how the e820 code works and mark
the page in question reserved as it does.
On 3 Dec 2002, Alan Cox wrote:
> On Tue, 2002-12-03 at 21:11, Richard B. Johnson wrote:
> > If you need a certain page reserved at boot-time you are out-of-luck.
>
> Wrong - you can specify the precise memory map of a box as well as use
> mem= to set the top of used memory. Its a painful way of marking a page
> and it only works for a page the kernel isnt loaded into.
short question - is it also possible to mark some "bad addresses" in a
quite similar way ? I know RAM is cheep these days but...
Memory with just one bad address or two would be good enough to be
able to use them in a desktop pc again if the kernel could make sure
that these addresses will never be accessed/used from anyone.
Next step for HA in servers then would be a memory raid ;-) but for
sure big blue holds some patents on this :(
--
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
56 69 73 69 74 http://www.zabbadoz.net/
On Tue, 2002-12-03 at 12:03, Duncan Sands wrote:
> I would like to reserve a particular page of physical memory when
> the kernel boots. By reserving I mean that no one else gets to read
> from it or write to it: it is mine. Any suggestions for the best way
> to go about this with a 2.5 kernel?
try having a look for the linux badmem patches i belive they might do
the same sort of thing.
James
On 3 Dec 2002, James Stevenson wrote:
| On Tue, 2002-12-03 at 12:03, Duncan Sands wrote:
| > I would like to reserve a particular page of physical memory when
| > the kernel boots. By reserving I mean that no one else gets to read
| > from it or write to it: it is mine. Any suggestions for the best way
| > to go about this with a 2.5 kernel?
|
| try having a look for the linux badmem patches i belive they might do
| the same sort of thing.
see http://badmem.sourceforge.net/
--
~Randy
On 3 Dec 2002, Alan Cox wrote:
> On Tue, 2002-12-03 at 21:11, Richard B. Johnson wrote:
> > If you need a certain page reserved at boot-time you are out-of-luck.
>
> Wrong - you can specify the precise memory map of a box as well as use
> mem= to set the top of used memory. Its a painful way of marking a page
> and it only works for a page the kernel isnt loaded into.
>
If you are refering to the "reserve=" kernel parameter, I don't
think it works for memory addresses that are inside existing RAM.
I guess if you used the "mem=" parameter to keep the kernel from
using that RAM, the combination might work, but I have never
tried it.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Bush : The Fourth Reich of America
At 08:25 AM 12/4/2002 -0500, Richard B. Johnson wrote:
>On 3 Dec 2002, Alan Cox wrote:
>
> > On Tue, 2002-12-03 at 21:11, Richard B. Johnson wrote:
> > > If you need a certain page reserved at boot-time you are out-of-luck.
> >
> > Wrong - you can specify the precise memory map of a box as well as use
> > mem= to set the top of used memory. Its a painful way of marking a page
> > and it only works for a page the kernel isnt loaded into.
> >
>
>If you are refering to the "reserve=" kernel parameter, I don't
>think it works for memory addresses that are inside existing RAM.
>I guess if you used the "mem=" parameter to keep the kernel from
>using that RAM, the combination might work, but I have never
>tried it.
reserve= is for IO ports (kernel/resource.c). I think Alan was referring to
mem=exactmap.
If Duncan didn't have the pesky requirement that his module work in an
unmodified kernel, it would be easy to use __alloc_bootmem() to reserve an
address range and expose via /proc. But alas...
-Mike
On Wed, 4 Dec 2002, Mike Galbraith wrote:
> At 08:25 AM 12/4/2002 -0500, Richard B. Johnson wrote:
> >On 3 Dec 2002, Alan Cox wrote:
> >
> > > On Tue, 2002-12-03 at 21:11, Richard B. Johnson wrote:
> > > > If you need a certain page reserved at boot-time you are out-of-luck.
> > >
> > > Wrong - you can specify the precise memory map of a box as well as use
> > > mem= to set the top of used memory. Its a painful way of marking a page
> > > and it only works for a page the kernel isnt loaded into.
> > >
> >
> >If you are refering to the "reserve=" kernel parameter, I don't
> >think it works for memory addresses that are inside existing RAM.
> >I guess if you used the "mem=" parameter to keep the kernel from
> >using that RAM, the combination might work, but I have never
> >tried it.
>
> reserve= is for IO ports (kernel/resource.c). I think Alan was referring to
> mem=exactmap.
>
> If Duncan didn't have the pesky requirement that his module work in an
> unmodified kernel, it would be easy to use __alloc_bootmem() to reserve an
> address range and expose via /proc. But alas...
>
> -Mike
>
Well that parameter is not documented in:
.../linux-2.4.18/Documentation/kernel-parameters.txt.
Perhaps it's a 2.5.++ thing.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Bush : The Fourth Reich of America
On Wed, 4 Dec 2002, Richard B. Johnson wrote:
| On Wed, 4 Dec 2002, Mike Galbraith wrote:
|
| > At 08:25 AM 12/4/2002 -0500, Richard B. Johnson wrote:
| > >On 3 Dec 2002, Alan Cox wrote:
| > >
| > > > On Tue, 2002-12-03 at 21:11, Richard B. Johnson wrote:
| > > > > If you need a certain page reserved at boot-time you are out-of-luck.
| > > >
| > > > Wrong - you can specify the precise memory map of a box as well as use
| > > > mem= to set the top of used memory. Its a painful way of marking a page
| > > > and it only works for a page the kernel isnt loaded into.
| > > >
| > >
| > >If you are refering to the "reserve=" kernel parameter, I don't
| > >think it works for memory addresses that are inside existing RAM.
| > >I guess if you used the "mem=" parameter to keep the kernel from
| > >using that RAM, the combination might work, but I have never
| > >tried it.
| >
| > reserve= is for IO ports (kernel/resource.c). I think Alan was referring to
| > mem=exactmap.
| >
| > If Duncan didn't have the pesky requirement that his module work in an
| > unmodified kernel, it would be easy to use __alloc_bootmem() to reserve an
| > address range and expose via /proc. But alas...
| >
|
| Well that parameter is not documented in:
|
| .../linux-2.4.18/Documentation/kernel-parameters.txt.
|
| Perhaps it's a 2.5.++ thing.
Patch for 'mem=exactmap' in 2.4 was submitted several weeks ago and
Alan merged it into -ac. It does need to be pushed to Marcelo...
--
~Randy
On Wednesday 04 December 2002 17:44, Mike Galbraith wrote:
> At 08:25 AM 12/4/2002 -0500, Richard B. Johnson wrote:
> >On 3 Dec 2002, Alan Cox wrote:
> > > On Tue, 2002-12-03 at 21:11, Richard B. Johnson wrote:
> > > > If you need a certain page reserved at boot-time you are out-of-luck.
> > >
> > > Wrong - you can specify the precise memory map of a box as well as use
> > > mem= to set the top of used memory. Its a painful way of marking a page
> > > and it only works for a page the kernel isnt loaded into.
> >
> >If you are refering to the "reserve=" kernel parameter, I don't
> >think it works for memory addresses that are inside existing RAM.
> >I guess if you used the "mem=" parameter to keep the kernel from
> >using that RAM, the combination might work, but I have never
> >tried it.
>
> reserve= is for IO ports (kernel/resource.c). I think Alan was referring to
> mem=exactmap.
>
> If Duncan didn't have the pesky requirement that his module work in an
> unmodified kernel, it would be easy to use __alloc_bootmem() to reserve an
> address range and expose via /proc. But alas...
I actually said I was happy to modify the kernel! As for __alloc_bootmem(),
based on my quick reading of the implementation in 2.5.50, I don't see how
you can be sure it will give you a particular physical page. I would like to
either get the page I want, or fail.
Thanks for your help,
Duncan.
At 07:15 AM 12/4/2002 +0100, Duncan Sands wrote:
>On Wednesday 04 December 2002 17:44, Mike Galbraith wrote:
> > At 08:25 AM 12/4/2002 -0500, Richard B. Johnson wrote:
> > >On 3 Dec 2002, Alan Cox wrote:
> > > > On Tue, 2002-12-03 at 21:11, Richard B. Johnson wrote:
> > > > > If you need a certain page reserved at boot-time you are out-of-luck.
> > > >
> > > > Wrong - you can specify the precise memory map of a box as well as use
> > > > mem= to set the top of used memory. Its a painful way of marking a page
> > > > and it only works for a page the kernel isnt loaded into.
> > >
> > >If you are refering to the "reserve=" kernel parameter, I don't
> > >think it works for memory addresses that are inside existing RAM.
> > >I guess if you used the "mem=" parameter to keep the kernel from
> > >using that RAM, the combination might work, but I have never
> > >tried it.
> >
> > reserve= is for IO ports (kernel/resource.c). I think Alan was referring to
> > mem=exactmap.
> >
> > If Duncan didn't have the pesky requirement that his module work in an
> > unmodified kernel, it would be easy to use __alloc_bootmem() to reserve an
> > address range and expose via /proc. But alas...
>
>I actually said I was happy to modify the kernel! As for __alloc_bootmem(),
>based on my quick reading of the implementation in 2.5.50, I don't see how
>you can be sure it will give you a particular physical page. I would like to
>either get the page I want, or fail.
Sorry, mixed you up with someone else. Seems to me you could just create a
new __setup("reservepage=", gimme_page) where gimme_page() allocates with
goal set, and frees/aborts if what it gets back isn't exactly what you
asked for.
-Mike
Crash dump after kexec also needs something similar, to
prevent the new kernel from allocating pages holding the dump from
the previous boot so that they aren't overwritten until the dump
gets written out. The pages can be accessed(read) for the purpose of
writeout. The Mission Critical implementation did this by patching
the kernel to mark these pages as reserved early during bootup,
much like the badmem mark pages as PG_Badmem.
There is a common theme running here of a "mark_claimed_pages"
logic during early bootup, and "is_claimed_page" check at
other places.
In the case of crash dump we have a fairly large number of
pages to be marked out this way. The layout is available in the
form of a map list, a pointer to which is passed on from the
previous reboot.
So if we are looking for very minimal infrastructure which all of
these can use, imposing a particular format in which such info
(about unavailable memory) be passed in could become either less
flexible or overgeneralized. Leaving the logic of identifying
pages to be claimed (not available to the kernel for allocation)
to the concerned subsystems appears to be a simpler and easier to
extend approach.
Is there a good way to avoid embedding calls to early mem
init code like mark_dump_pages, mark_bad_pages, mark_my_pages,
etc and instead have each of these subsystems specify interest
(a special section may be an overkill) so their corresponding
routines get called ?
Regards
Suparna
In article <[email protected]> Randy.Dunlap wrote:
> On 3 Dec 2002, James Stevenson wrote:
> | On Tue, 2002-12-03 at 12:03, Duncan Sands wrote:
> | > I would like to reserve a particular page of physical memory when
> | > the kernel boots. By reserving I mean that no one else gets to read
> | > from it or write to it: it is mine. Any suggestions for the best way
> | > to go about this with a 2.5 kernel?
> |
> | try having a look for the linux badmem patches i belive they might do
> | the same sort of thing.
> see http://badmem.sourceforge.net/
> --
> ~Randy
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Suparna Bhattacharya ([email protected])
Linux Technology Center
IBM Software Labs, India
Followup to: <[email protected]>
By author: "Randy.Dunlap" <[email protected]>
In newsgroup: linux.dev.kernel
>
> Patch for 'mem=exactmap' in 2.4 was submitted several weeks ago and
> Alan merged it into -ac. It does need to be pushed to Marcelo...
>
Once again, with feeling...
DON'T CALL IT mem=.
mem= is part of the boot protocol.
Call it memmap= or something, or you'll break boot loaders in weird
and subtle ways.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
> Followup to:
> <[email protected]> By author:
> "Randy.Dunlap" <[email protected]>
> In newsgroup: linux.dev.kernel
>>
>> Patch for 'mem=exactmap' in 2.4 was submitted several weeks ago and Alan
>> merged it into -ac. It does need to be pushed to Marcelo...
>>
>
> Once again, with feeling...
>
> DON'T CALL IT mem=.
>
> mem= is part of the boot protocol.
> Call it memmap= or something, or you'll break boot loaders in weird and
> subtle ways.
OK, with feeling:
I agree with you since the boot protocol is well-defined.
Just to be clear, my comment was referring to
Documentation/kernel-parameters.txt, not to any C code.
And it would really be helpful to catch issues like this soon
after they happen...
Thanks,
~Randy
Followup to: <32981.4.64.238.61.1046844111.squirrel@http://www.osdl.org>
By author: "Randy.Dunlap" <[email protected]>
In newsgroup: linux.dev.kernel
>
> OK, with feeling:
>
> I agree with you since the boot protocol is well-defined.
>
> Just to be clear, my comment was referring to
> Documentation/kernel-parameters.txt, not to any C code.
>
> And it would really be helpful to catch issues like this soon
> after they happen...
>
Unfortunately last time I commented on this the response was roughly
"well, the patch already made it into Linus' kernel, it's too late to
fix it now." That isn't exactly a very helpful response.
The mem= parameter has the semantic in the i386/PC boot protocol that
it specifies the top address of the usable memory region that begins
at 0x100000. It's a bit of a wart that the boot loaders have to be
aware of this, but it's so and it's been so for a very long time.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
On 5 Mar 2003 07:04:51 -0800
"H. Peter Anvin" <[email protected]> wrote:
| Followup to: <32981.4.64.238.61.1046844111.squirrel@http://www.osdl.org>
| By author: "Randy.Dunlap" <[email protected]>
| In newsgroup: linux.dev.kernel
| >
| > OK, with feeling:
| >
| > I agree with you since the boot protocol is well-defined.
| >
| > Just to be clear, my comment was referring to
| > Documentation/kernel-parameters.txt, not to any C code.
| >
| > And it would really be helpful to catch issues like this soon
| > after they happen...
| >
|
| Unfortunately last time I commented on this the response was roughly
| "well, the patch already made it into Linus' kernel, it's too late to
| fix it now." That isn't exactly a very helpful response.
I don't see why it's too late. How can it be too late?
Ah, because it's already made it into 2.4?
| The mem= parameter has the semantic in the i386/PC boot protocol that
| it specifies the top address of the usable memory region that begins
| at 0x100000. It's a bit of a wart that the boot loaders have to be
| aware of this, but it's so and it's been so for a very long time.
So it's the top of the 0x100000-mem physical linear memory region
(i.e., no gaps)?
--
~Randy
Randy.Dunlap wrote:
> |
> | Unfortunately last time I commented on this the response was roughly
> | "well, the patch already made it into Linus' kernel, it's too late to
> | fix it now." That isn't exactly a very helpful response.
>
> I don't see why it's too late. How can it be too late?
> Ah, because it's already made it into 2.4?
>
More because people don't want to fix their mistakes, I suspect :(
I don't know who originally started adding stuff to "mem=", but I still
feel it needs to be backed out and renamed.
> | The mem= parameter has the semantic in the i386/PC boot protocol that
> | it specifies the top address of the usable memory region that begins
> | at 0x100000. It's a bit of a wart that the boot loaders have to be
> | aware of this, but it's so and it's been so for a very long time.
>
> So it's the top of the 0x100000-mem physical linear memory region
> (i.e., no gaps)?
Correct.
Hi!
> > OK, with feeling:
> >
> > I agree with you since the boot protocol is well-defined.
> >
> > Just to be clear, my comment was referring to
> > Documentation/kernel-parameters.txt, not to any C code.
> >
> > And it would really be helpful to catch issues like this soon
> > after they happen...
> >
>
> Unfortunately last time I commented on this the response was roughly
> "well, the patch already made it into Linus' kernel, it's too late to
> fix it now." That isn't exactly a very helpful response.
>
> The mem= parameter has the semantic in the i386/PC boot protocol that
> it specifies the top address of the usable memory region that begins
> at 0x100000. It's a bit of a wart that the boot loaders have to be
> aware of this, but it's so and it's been so for a very long time.
Really? So user has to know where ACPI tables are and specify less
than that on mem= command line? That seems very
counter-intuitive. [Ahha, its probaly okay because e820 saves you.]
What do you pass on 4GB machine as mem= parameter? AFAIK those beasts
have hole at 3.75G. [Hopefully bigmem machines have working e820
tables?]
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
Pavel Machek wrote:
>
> Really? So user has to know where ACPI tables are and specify less
> than that on mem= command line? That seems very
> counter-intuitive. [Ahha, its probaly okay because e820 saves you.]
>
> What do you pass on 4GB machine as mem= parameter? AFAIK those beasts
> have hole at 3.75G. [Hopefully bigmem machines have working e820
> tables?]
>
If you pass mem= you have to pass mem=3840M. Yes, it sucks, but if you
genuinely have a machine which is so fucked up that you can't rely on
the memory map the BIOS presents to you, you have problems to begin with.
Oh yes, this is why GRUB passing the mem= parameter gratuitously was
beyond total and complete brainfuckage.
-hpa
Hi!
> > Really? So user has to know where ACPI tables are and specify less
> > than that on mem= command line? That seems very
> > counter-intuitive. [Ahha, its probaly okay because e820 saves you.]
> >
> > What do you pass on 4GB machine as mem= parameter? AFAIK those beasts
> > have hole at 3.75G. [Hopefully bigmem machines have working e820
> > tables?]
> >
>
> If you pass mem= you have to pass mem=3840M. Yes, it sucks, but if you
> genuinely have a machine which is so fucked up that you can't rely on
> the memory map the BIOS presents to you, you have problems to begin with.
>
> Oh yes, this is why GRUB passing the mem= parameter gratuitously was
> beyond total and complete brainfuckage.
Okay; which mem= options you want killed?
What about this?
Pavel
--- clean/arch/i386/kernel/setup.c 2003-03-06 23:25:14.000000000 +0100
+++ linux/arch/i386/kernel/setup.c 2003-03-08 00:18:21.000000000 +0100
@@ -527,6 +527,9 @@
* to <mem>, overriding the bios size.
* "mem=XXX[KkmM]@XXX[KkmM]" defines a memory region from
* <start> to <start>+<mem>, overriding the bios size.
+ *
+ * HPA tells me bootloaders need to parse mem=, so no new
+ * option should be mem=
*/
if (c == ' ' && !memcmp(from, "mem=", 4)) {
if (to != command_line)
@@ -535,8 +538,24 @@
from += 9+4;
clear_bit(X86_FEATURE_PSE, boot_cpu_data.x86_capability);
disable_pse = 1;
- } else if (!memcmp(from+4, "exactmap", 8)) {
- from += 8+4;
+ } else {
+ /* If the user specifies memory size, we
+ * limit the BIOS-provided memory map to
+ * that size. exactmap can be used to specify
+ * the exact map. mem=number can be used to
+ * trim the existing memory map.
+ */
+ unsigned long long start_at, mem_size;
+
+ mem_size = memparse(from+4, &from);
+ }
+ }
+
+ if (c == ' ' && !memcmp(from, "memmap=", 7)) {
+ if (to != command_line)
+ to--;
+ if (!memcmp(from+7, "exactmap", 8)) {
+ from += 8+7;
e820.nr_map = 0;
userdef = 1;
} else {
@@ -548,7 +567,7 @@
*/
unsigned long long start_at, mem_size;
- mem_size = memparse(from+4, &from);
+ mem_size = memparse(from+7, &from);
if (*from == '@') {
start_at = memparse(from+1, &from);
add_memory_region(start_at, mem_size, E820_RAM);
@@ -565,6 +584,7 @@
}
}
+
/* "acpi=off" disables both ACPI table parsing and interpreter init */
if (c == ' ' && !memcmp(from, "acpi=off", 8))
acpi_disabled = 1;
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
Pavel Machek wrote:
>
> Okay; which mem= options you want killed?
>
Anything that doesn't match the regexp (in Perl syntax):
/^mem=(0[0-7]*|[1-9][0-9]*|0x[0-9a-f]+)[kmg]$/i
> What about this?
Looks good to me.
> Pavel
>
> --- clean/arch/i386/kernel/setup.c 2003-03-06 23:25:14.000000000 +0100
> +++ linux/arch/i386/kernel/setup.c 2003-03-08 00:18:21.000000000 +0100
> @@ -527,6 +527,9 @@
> * to <mem>, overriding the bios size.
> * "mem=XXX[KkmM]@XXX[KkmM]" defines a memory region from
> * <start> to <start>+<mem>, overriding the bios size.
> + *
> + * HPA tells me bootloaders need to parse mem=, so no new
> + * option should be mem=
> */
> if (c == ' ' && !memcmp(from, "mem=", 4)) {
> if (to != command_line)
> @@ -535,8 +538,24 @@
> from += 9+4;
> clear_bit(X86_FEATURE_PSE, boot_cpu_data.x86_capability);
> disable_pse = 1;
> - } else if (!memcmp(from+4, "exactmap", 8)) {
> - from += 8+4;
> + } else {
> + /* If the user specifies memory size, we
> + * limit the BIOS-provided memory map to
> + * that size. exactmap can be used to specify
> + * the exact map. mem=number can be used to
> + * trim the existing memory map.
> + */
> + unsigned long long start_at, mem_size;
> +
> + mem_size = memparse(from+4, &from);
> + }
> + }
> +
> + if (c == ' ' && !memcmp(from, "memmap=", 7)) {
> + if (to != command_line)
> + to--;
> + if (!memcmp(from+7, "exactmap", 8)) {
> + from += 8+7;
> e820.nr_map = 0;
> userdef = 1;
> } else {
> @@ -548,7 +567,7 @@
> */
> unsigned long long start_at, mem_size;
>
> - mem_size = memparse(from+4, &from);
> + mem_size = memparse(from+7, &from);
> if (*from == '@') {
> start_at = memparse(from+1, &from);
> add_memory_region(start_at, mem_size, E820_RAM);
> @@ -565,6 +584,7 @@
> }
> }
>
> +
> /* "acpi=off" disables both ACPI table parsing and interpreter init */
> if (c == ' ' && !memcmp(from, "acpi=off", 8))
> acpi_disabled = 1;
>
>
> Pavel Machek wrote:
>>
>> Okay; which mem= options you want killed?
>>
>
> Anything that doesn't match the regexp (in Perl syntax):
>
> /^mem=(0[0-7]*|[1-9][0-9]*|0x[0-9a-f]+)[kmg]$/i
>
>> What about this?
>
> Looks good to me.
Thanks, Pavel. You beat me to it.
~Randy