linux-kernel - Re: [PATCH] kconfig: untangle EXPERT and EMBEDDED

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.1201180113030.19730@chino.kir.corp.google.com>
Date:	Wed, 18 Jan 2012 01:19:44 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Andrew Jones <drjones@...hat.com>
cc:	Arnd Bergmann <arnd@...db.de>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, mingo@...e.hu,
	david.woodhouse@...el.com, gregkh@...e.de, davem@...emloft.net,
	axboe@...nel.dk, holt@....com, linux-arch@...r.kernel.org,
	linux@....linux.org.uk, hskinnemoen@...il.com,
	egtvedt@...fundet.no, msalter@...hat.com, a-jacquiot@...com,
	starvik@...s.com, jesper.nilsson@...s.com, dhowells@...hat.com,
	takata@...ux-m32r.org, geert@...ux-m68k.org,
	yasutake.koichi@...panasonic.com, jonas@...thpole.se,
	kyle@...artin.ca, deller@....de, jejb@...isc-linux.org,
	chris@...kel.net, greg@...ah.com, davej@...hat.com,
	airlied@...ux.ie, jkosina@...e.cz, mchehab@...radead.org,
	johannes@...solutions.net, linville@...driver.com
Subject: Re: [PATCH] kconfig: untangle EXPERT and EMBEDDED

On Wed, 18 Jan 2012, Andrew Jones wrote:

> > > Now changing it, i.e. making it conform more closely to its name and only
> > > affect embedded related options, you can't do. If you were to do so, then
> > > you would lose backward compatibility. How do you know there aren't users
> > > that started using EMBEDDED for the non-embedded side effects?
> > 
> > That's why they're now using EXPERT.
> 
> How do you know they've all switched?
> 

Because existing CONFIG_EMBEDDED configs now automatically enable it since 
my patch was merged a year ago.  Users who haven't upgraded since then and 
run make oldconfig will do so in the future and we're not risking breaking 
backwards compatibility at least until a sufficient amount of time has 
passed.

> > No, because they've already enabled EXPERT.  You can't have EMBEDDED=y and 
> > EXPERT=n.  That's what this little thing called "select" does.  After a 
> > sufficient amount of time passes and all options that are important only 
> > for embedded users have been either extended for EMBEDDED or replaced only 
> > be EMBEDDED, you can get rid of the "select" without losing backwards 
> > compatibility.
> 
> How do you define a sufficient amount of time? How do you know everyone
> else agrees with that definition? OIOW, where is it documented? If it is
> documented, then how do you know everyone will read it and comply to it?
> 

An example: when I rewrote the kernel oom killer and deprecated 
/proc/pid/oom_adj, we did this:

 - mapped writes to oom_adj to the new tunable, oom_score_adj,

 - emitted a warning when userspace wrote to oom_adj a single time,

 - a year later, emitted a warning every time userspace writes to
   oom_adj, and

 - in September of 2012, the tunable will be removed entirely.

This gives userspace two years to covert before the tunable is dropped 
entirely.  We can't keep it around forever, but we're careful not to 
suddenly drop existing users without some due diligence.  It's added to 
Documentation/feature-removal-schedule.txt like all feature removals are.  
We can do no better without a huge maintenance burden.

We could add that CONFIG_EMBEDDED will stop automatically enabling 
CONFIG_EXPERT in January 2014 to 
Documentation/feature-removal-schedule.txt as well.  That certainly seems 
like a good idea.

However, we've now diverged entirely from your patch in this thread.
--
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/