Re: [PATCH] power: make goldfish option have a dependency on goldfish

[Paul Gortmaker]

On Wed, Feb 27, 2013 at 6:18 PM, Anton Vorontsov <anton@xxxxxxxxxx> 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@xxxxxxx>
>> Cc: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
>> ---
>
> 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@xxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/