Re: [PATCH] Clarify i386/Kconfig explanation of the HIGHMEM config options

[Bill Davidsen <davidsen@tmr.com>]

thunder7@xs4all.nl wrote:
> From: Theodore Tso <tytso@mit.edu>
> Date: Thu, Dec 14, 2006 at 10:17:45AM -0500
> > Remove an (incorrect) assertion that NOHIGHMEM is right for more
> > users, since most systems are coming with at least 1G of memory these
> > days, and even some laptops have up 4G of memory.
>
> Given this (on a system with 1G of memory, this option shouldn't be
> used)
>
> >  	  If you are compiling a kernel which will never run on a machine with
> > -	  more than 1 Gigabyte total physical RAM, answer "off" here (default
> > -	  choice and suitable for most users). This will result in a "3GB/1GB"
> > -	  split: 3GB are mapped so that each process sees a 3GB virtual memory
> > -	  space and the remaining part of the 4GB virtual memory space is used
> > -	  by the kernel to permanently map as much physical memory as
> > -	  possible.
> > +	  more than 1 Gigabyte total physical RAM, answer "off" here.
>
> wouldn't 
>
> +	  1 Gigabyte or more total physical RAM, answer "off" here.
>
> make clearer that even with 1G memory, you shouldn't use this option?
> Since 1G is quite common, we should, IMHO, be clear about that case.

Actually, if you want it to be perfectly clear to people who don't keep 
x86 spec sheets in the bathroom for spare time study, a redundant config 
option for NX would be required. Then the logic would be:
   PAE = MEM>4G || NX
as far as the actual build was concerned. Or you could reject NX in 
config unless PAE was selected.

I don't think you will avoid confusion when you have two unrelated 
reasons for enabling the same feature.

--
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979
-
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/