linux-kernel - Re: [PATCH 24/28] Remove DEPRECATED

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: <52F80C4E.5040805@roeck-us.net>
Date:	Sun, 09 Feb 2014 15:16:30 -0800
From:	Guenter Roeck <linux@...ck-us.net>
To:	Richard Weinberger <richard@....at>,
	Paul Bolle <pebolle@...cali.nl>
CC:	David Howells <dhowells@...hat.com>,
	Koichi Yasutake <yasutake.koichi@...panasonic.com>,
	"moderated list:PANASONIC MN10300..." <linux-am33-list@...hat.com>,
	open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 24/28] Remove DEPRECATED

On 02/09/2014 01:38 PM, Richard Weinberger wrote:
> Am 09.02.2014 22:35, schrieb Guenter Roeck:
>> I could understand if you would replace DEPRECATED with BROKEN,
>> but causing a potentially large number of broken builds and
>> then leave it to others to clean up the resulting mess doesn't
>> make any sense to me and should, in my opinion, be rejected.
>
> Currently the mess is hidden by bad Kconfig dependencies.
> We have to face it. :)
>

You can make the breakage obvious by using BROKEN instead
of DEPRECATED. Then it can be fixed.

Otherwise you could, using your logic, remove all BROKEN
dependencies as well (all 90 or so of them). That symbol,
after all, is just as orphan as DEPRECATED.

The point here is to not unnecessarily introduce build problems.
There are people out there trying to ensure that no new build
breakages are introduced. By making X configurations
non-buildable, all you accomplish is to ensure that no one will
be able to discover real new build problems anymore, because
those new problems will all disappear in the build breakage
noise you introduced.

So, in practice, all you accomplish is to make the kernel
less maintainable. If that is your goal, mission accomplished.
Otherwise I would kindly ask you to reconsider.

Note that I would not mind some big cleanup effort to simply
remove all code marked as BROKEN, and I would be more than
happy to assist in such an effort.

However, breaking builds on purpose in the hope that someone
would magically show up and fix it is just plain wrong.

Note that I do not refer to a specific platform.

Guenter

--
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/