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
| ||
|
Date: Wed, 27 Feb 2013 19:48:38 -0500 From: Paul Gortmaker <paul.gortmaker@...driver.com> To: Anton Vorontsov <anton@...msg.org> Cc: linux-kernel@...r.kernel.org, David Woodhouse <dwmw2@...radead.org> Subject: Re: [PATCH] power: make goldfish option have a dependency on goldfish On Wed, Feb 27, 2013 at 6:18 PM, Anton Vorontsov <anton@...msg.org> wrote: > Hello Paul, > > On Wed, Feb 27, 2013 at 01:27:46PM -0500, Paul Gortmaker wrote: >> Nearly all the other goldfish peripherals (mtd, keyboard, etc) >> have a dependency on the main platform's GOLDFISH Kconfig item, >> but this one got skipped, so add it. >> >> Cc: Anton Vorontsov <cbou@...l.ru> >> Cc: David Woodhouse <dwmw2@...radead.org> >> Signed-off-by: Paul Gortmaker <paul.gortmaker@...driver.com> >> --- > > Our policy, IIRC, has been quite the opposite: we try to put as little > dependencies as possible, letting drivers build on all different kinds of > configs/arches/machines. Why? It helps us keep the code in a good shape. > > So, unless there are any unresolable build issues with the driver, I > believe we should keep it as is. Hi Anton, Yes, I have heard that kind of argument before, but assuming you mean "our policy" as being the kernel, and kernel people in general, allow me to point out some observations. --what is done here for the power subsystem is inconsistent with what the goldfish additions did for a lot of other subsystems (as mentioned in the commit log). Most of the other goldfish subsystems had added a clear dependency on the main GOLDFISH option. Only power and video had the missing dependencies. --the argument of it keeping "the code in a good shape" is kind of weak, in that it assumes the possible bugs will trigger out right compile failures and warnings. Some may, but it is a very very small subset. Plus, say for example, a driver is PPC specific, and we uncover an endian bug in it for little endian. Well, so what? We are just spinning our wheels fixing things for the academic value. --we really _don't_ have a global policy to take the widest possible build coverage after all. For example, we do not build MIPS specific drivers for arch=sparc, and we do not build m68k specific drivers for ARM. Nor should we start doing such a thing (for reasons listed below). --forcing pointless build coverage impacts everyone. Consider for a moment, the linux-next tree, or anyone else doing routine coverage builds. If we adopt the "build everything even though you can't run this code on that platform" policy, that build coverage grows out of control, in terms of time spent. The linux-next compile queue as it is today barely gets completed within a 24h window. --why shouldn't we restrict the maintenance overhead of CONFIG_FOO to people who really do care about supporting and testing and updating features conditional on CONFIG_FOO? Given the size of the kernel today, this seems to make sense in terms of developer "load balancing". If you don't want to take the commit, I won't argue it any further, but I genuinely do hope the above logical arguments perhaps might cause you to change your mind. Thanks, Paul. -- > > Thanks, > > Anton > >> drivers/power/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig >> index 9e00c38..d314528 100644 >> --- a/drivers/power/Kconfig >> +++ b/drivers/power/Kconfig >> @@ -348,7 +348,7 @@ config AB8500_BM >> >> config BATTERY_GOLDFISH >> tristate "Goldfish battery driver" >> - depends on GENERIC_HARDIRQS >> + depends on GENERIC_HARDIRQS && GOLDFISH >> help >> Say Y to enable support for the battery and AC power in the >> Goldfish emulator. >> -- >> 1.8.1.2 > -- > 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/ -- 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