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
| ||
|
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/
Powered by blists - more mailing lists