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:	Tue, 29 Jul 2008 15:04:55 -0500
From:	Cliff Wickman <cpw@....com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Nick Piggin <nickpiggin@...oo.com.au>, steiner@....com,
	mingo@...e.hu, linux-kernel@...r.kernel.org
Subject: Re: Comments on UV tlb flushing

On Tue, Jul 29, 2008 at 10:46:41AM -0700, Jeremy Fitzhardinge wrote:
> Cliff Wickman wrote:
>> But if the tlb_uv.o code should be present in "every" distro x86 kernel
>> I don't see the point of having to configure it in.  Why not just
>> configure it out for small (embedded) kernels?
>
> Because it's not an binary thing.  Lots of people who are compiling  
> their own kernels for specialized uses don't set CONFIG_EMBEDDED, but  
> also don't want a kitchen sink kernel.  6k isn't that much, but if every  
> obscure platform enabled some always-on code it rapidly starts to build 
> up.

But UV will not be obscure! It will be common among x86_64 :)  
I know what you're talking about.  It may sometimes be useful to turn
off chunks of code you don't need. 
But is the specialized application of 64-bit processors big enough to
warrant the feature?
The size of most any 64-bit system would, I would think, make 6k of
code insignificant.
And the more options you add, the more likely someone will pick
combinations that won't work together.

> Basically, if you want to make sure if you're going to get some level of  
> distro support, you need to make contact with the distros directly and  
> talk about what you'd like them to do.
>    J
And we do. And could reasonably expect that they would turn on that
option for x86_64 kernels.  We'd just, of course, rather not have to watch
and prompt to be sure all x86_64 kernels will run on our hardware.

-Cliff
-- 
Cliff Wickman
Silicon Graphics, Inc.
cpw@....com
(651) 683-3824
--
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