linux-kernel - Re: linux-next: Tree for Sep 19

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

Date:	Fri, 19 Sep 2014 19:40:45 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	David Miller <davem@...emloft.net>, anish@...lsio.com
CC:	rdunlap@...radead.org, sfr@...b.auug.org.au,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	JBottomley@...allels.com, mchan@...adcom.com
Subject: Re: linux-next: Tree for Sep 19

On 09/19/2014 07:08 PM, David Miller wrote:
> From: Anish Bhatt <anish@...lsio.com>
> Date: Sat, 20 Sep 2014 01:43:05 +0000
>
>> Original config causing issues can be seen here :
>> https://lkml.org/lkml/2014/9/9/500
>>
>> As CNIC depends on IPV6, CNIC can be only compiled as a module when IPV6 is
>> compiled as a module. This was the patch I originally commited. Previous
>> behaviour was to disable all ipv6 code in such a case. However, having bnx2fc/i
>>   as built-in overrides CNIC's tristate from m to built-in (as they select CNIC),
>>   causing build issues. As far as I know, there is no way to control the state
>> that select sets.
>
> Really, nothing that has dependencies should be "select"'d, ever.
>
> What people hack up is that they try to do this, and "make it work"
> by "select"'ing all of the selected object's dependencies.  And
> then you have to do this recursively for dependencies which have
> dependencies.
>
> This is really incredibly stupid.
>
> And once something in that chain gains a new dependency, all of
> these "select" instances break.
>
> I really want all of these netlink users to "depend" on "NET"
> rather than "select" it, and so on and so forth down to the
> users of these netlink using subsystems.
>

Sure, that makes sense on some level, but you would have to make sure
that any changes made are clean and don't break existing configurations,
and/or you would have to make sure that all affected configurations are
updated as needed. A single-line change in a configuration file, to hell
with the consequences, just doesn't cut it.

We already know that 11 out of 55 mips configurations are broken in
linux-next. I don't even want to know what else is broken. That is
a pretty high price to pay to achieve purity.

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/