linux-kernel - Re: CONFIG_EXPERT is a booby trap

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]

Message-ID: <alpine.DEB.2.00.1210012045580.31644@chino.kir.corp.google.com>
Date:	Mon, 1 Oct 2012 20:49:49 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Tim Shepard <shep@...m.mit.edu>
cc:	linux-kernel@...r.kernel.org
Subject: Re: CONFIG_EXPERT is a booby trap

On Sun, 30 Sep 2012, Tim Shepard wrote:

> And may I suggest that CONFIG_EXPERT should be factored into two
> CONFIGs, one of which makes configuration things visible, and another
> which changes the default values to something more appropriate for
> embedded systems (perhaps call it CONFIG_EMBEDDED_DEFAULTS).  That way
> you'd have to select CONFIG_EXPERT, and then select the
> CONFIG_EMBEDDED_DEFAULTS option that CONFIG_EXPERT made visible to
> actually change any configuration, and the documentation for
> CONFIG_EMBEDDED_DEFAULTS could explain that it changes defaults
> throughout the tree (and selecting CONFIG_EXPERT alone would not go off
> and muck things up with no warning).
> 

I think you can get away with changing everything that is doing "default 
!EXPERT" to do "default !EMBEDDED" since it's usually only done for things 
that are known not to be interesting for the embedded world and 
significantly increase the size of the kernel memory footprint.  What it's 
really saying is to "enable it by default on everything that doesn't need 
to make the smallest kernel possible."

Aside from that, separating CONFIG_EXPERT from CONFIG_EMBEDDED is 
something that has been discussed a few times and can be done when it 
makes clear sense and you can get consensus on the change.  We always 
accept patches.
--
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/