lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 15 Dec 2006 12:06:12 -0500
From:	Bill Davidsen <davidsen@....com>
To:	Jurriaan <thunder7@...all.nl>,
	Linux Kernel mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Clarify i386/Kconfig explanation of the HIGHMEM config
 options

thunder7@...all.nl wrote:
> From: Theodore Tso <tytso@....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@....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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ