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

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

[Paul Gortmaker]

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@mail.ru>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 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

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

[Anton Vorontsov]

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@mail.ru>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.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.

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

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@enomsg.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@mail.ru>
>> Cc: David Woodhouse <dwmw2@infradead.org>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

[Anton Vorontsov]

On Wed, Feb 27, 2013 at 07:48:38PM -0500, Paul Gortmaker wrote:
[...]
> 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.

As a maintainer of drivers/power/, I have to keep things in a sane state,
which means, that I want to compile-test the patches that I am merging.

Testing patches takes time, and if I have to do it for all bunch of
different machines and architectures, it becomes mess and unmanageable. In
another words, it is easier for me to use as little different
setups/.configs/cross-compilers/trees/etc as possible.

For example, here is the scenario:

- someone sends me a patch for goldfish driver;
- I quickly compile it on my [underpowered] x86 laptop without need for
  cross-compilation and special configs;
- It compiles fine, produces no warnings, so I happily send out the
  'Applied, thanks!' email;

Now, with your patch:

- Someone sends me a patch for goldfish driver;
- I starting to look for my cross-compilers collections, making all the
  environment setups, setting up a new build tree, looking for the
  outdated goldfish config, the ARM thing fails to build somewhere in
  arch/arm/plat-foo and drivers/mfd/bar. I become grumpy... and, you might
  not believe me, I open and edit drivers/power/Kconfig and remove
  needless 'depends on' (that is, I actually do these kind of things when
  I feel lazy enough).

Do you agree that without the additional deps life is easier for me? :)

If so, please do help me and the rest of the maintainers: instead of
adding the unneeded deps, for consistency just remove those which are not
needed.

Thanks,

Anton

p.s. Quick answers for the rest of your arguments:

> The linux-next compile queue as it is today barely gets completed within
>  a 24h window.

So, it is large enough already, and nothing we can do about it, things are
growing. But the good news is that no human attention is needed to compile
things. That is what machines are for. :)

> --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".

You don't have to enable/fix everything. Some things become broken, so
just disable them for the time being. But when people stumble upon broken
drivers, the drivers are either get fixed, or removed (if no one wants to
fix it). Sweeping drivers under 'depends on' doesn't do anything good in
this regard, IMO.

If we notice that goldfish is broken for long time and nobody cares to fix
it, then it is a good time to think about its removal. Since goldfish has
nothing goldfish-specific, it can be broeken only in a generic way, so if
it is broken on x86, it is as well broken for ARM.

> If you don't want to take the commit, I won't argue it any further

I don't want to take it for a reason, but I do care whether my reasons
make sense to you.

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

[Paul Gortmaker]

On Wed, Feb 27, 2013 at 8:35 PM, Anton Vorontsov <anton@enomsg.org> wrote:
> On Wed, Feb 27, 2013 at 07:48:38PM -0500, Paul Gortmaker wrote:
> [...]
>> 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.
>
> As a maintainer of drivers/power/, I have to keep things in a sane state,
> which means, that I want to compile-test the patches that I am merging.

As you should, and nobody will fault you for that objective.

>
> Testing patches takes time, and if I have to do it for all bunch of
> different machines and architectures, it becomes mess and unmanageable. In

So, you actually want my change then -- you do not want to test for
goldfish power issues unless goldfish is selected.  This is how I see
the situation.

> another words, it is easier for me to use as little different
> setups/.configs/cross-compilers/trees/etc as possible.
>
> For example, here is the scenario:
>
> - someone sends me a patch for goldfish driver;
> - I quickly compile it on my [underpowered] x86 laptop without need for
>   cross-compilation and special configs;
> - It compiles fine, produces no warnings, so I happily send out the
>   'Applied, thanks!' email;

I can not see how the above is at all relevant.  If someone sends you a
patch for ARCH != x86, then your workflow will fail, regardless of what
actually is within the patch.  As a maintainer, you need to be able to
handle cross compiles -- you can't escape the slightly more detailed
testing requirements we need to get from subsystem maintainers.  There
are cross compile capable toolchains on kernel.org, and I use them
regularly before sending out changes that can impact multiple arch.

ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/

We can forgive individual contributors for not being arch aware, but
at the subsystem maintainer level, folks should be arch aware, and
doing regular x-compiles.

> Now, with your patch:
>
> - Someone sends me a patch for goldfish driver;
> - I starting to look for my cross-compilers collections, making all the
>   environment setups, setting up a new build tree, looking for the
>   outdated goldfish config, the ARM thing fails to build somewhere in
>   arch/arm/plat-foo and drivers/mfd/bar. I become grumpy... and, you might
>   not believe me, I open and edit drivers/power/Kconfig and remove

I am confused here.  If there are correct depends lines here in the Kconfig,
then it _protects_ you from suffering like this.  Yet, you want me to think
that it adds new work, new cross compile requirements and so on.  I do
not see how that can possibly happen.

>   needless 'depends on' (that is, I actually do these kind of things when
>   I feel lazy enough).
>
> Do you agree that without the additional deps life is easier for me? :)

No, I do not agree.  In fact I see it as totally the opposite.  But I already
said that I would not pursue this further, based only on differing points
of view, and so, after sending this, I will adhere to that now.

> If so, please do help me and the rest of the maintainers: instead of
> adding the unneeded deps, for consistency just remove those which are not
> needed.

I think what I sent matches the above criteria.  If you still are convinced
that I am incorrect in this regard, then I hope you can point to explicit
specifics that can convince me I am wrong.  At the moment I do not
see anything to convince me that is the case.  We are expanding work
for maintainers, testers, and people doing build coverage for no return
whatsoever, including yourself.

Thanks,
Paul.
--

>
> Thanks,
>
> Anton
>
> p.s. Quick answers for the rest of your arguments:
>
>> The linux-next compile queue as it is today barely gets completed within
>>  a 24h window.
>
> So, it is large enough already, and nothing we can do about it, things are
> growing. But the good news is that no human attention is needed to compile
> things. That is what machines are for. :)
>
>> --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".
>
> You don't have to enable/fix everything. Some things become broken, so
> just disable them for the time being. But when people stumble upon broken
> drivers, the drivers are either get fixed, or removed (if no one wants to
> fix it). Sweeping drivers under 'depends on' doesn't do anything good in
> this regard, IMO.
>
> If we notice that goldfish is broken for long time and nobody cares to fix
> it, then it is a good time to think about its removal. Since goldfish has
> nothing goldfish-specific, it can be broeken only in a generic way, so if
> it is broken on x86, it is as well broken for ARM.
>
>> If you don't want to take the commit, I won't argue it any further
>
> I don't want to take it for a reason, but I do care whether my reasons
> make sense to you.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

[Anton Vorontsov]

On Wed, Feb 27, 2013 at 09:17:06PM -0500, Paul Gortmaker wrote:
[...]
> > Testing patches takes time, and if I have to do it for all bunch of
> > different machines and architectures, it becomes mess and unmanageable. In
> 
> So, you actually want my change then -- you do not want to test for
> goldfish power issues unless goldfish is selected.  This is how I see
> the situation.

No, I want to cover as much as possible code in one go. This is not 'all
or nothing' thing, plus I can't test whether the driver actually works,
but testing that it compiles is a great deal, because quite often patches
just don't compile. :-)

And part of my task is to catch the trivial errors (but not all! 99% of
them). Putting unneeded(!) 'depends on' makes my life harder.

> > another words, it is easier for me to use as little different
> > setups/.configs/cross-compilers/trees/etc as possible.
> >
> > For example, here is the scenario:
> >
> > - someone sends me a patch for goldfish driver;
> > - I quickly compile it on my [underpowered] x86 laptop without need for
> >   cross-compilation and special configs;
> > - It compiles fine, produces no warnings, so I happily send out the
> >   'Applied, thanks!' email;
> 
> I can not see how the above is at all relevant.  If someone sends you a
> patch for ARCH != x86, then your workflow will fail, regardless of what
> actually is within the patch.

Again, it is not 'all or nothing'. If the patch, supposedly, for Alpha, I
won't even bother compile-testing it. Instead, I will spend more brain
power to look into the patch, and see if it is actually sane. Doing so
will take 5 seconds more of my time for this single patch for the rare
architecture, instead of *hours* setting up cross tools and compile the
patch for this weird arch.

> As a maintainer, you need to be able to
> handle cross compiles -- you can't escape the slightly more detailed
> testing requirements we need to get from subsystem maintainers.  There
> are cross compile capable toolchains on kernel.org, and I use them
> regularly before sending out changes that can impact multiple arch.
> 
> ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/
> 
> We can forgive individual contributors for not being arch aware, but
> at the subsystem maintainer level, folks should be arch aware, and
> doing regular x-compiles.

Seriously? You mean, as a maintainer, I must compile it for every weird
architecture out there? No way. I care not to break 99% users -- x86, and
maybe ARM. If MIPS guys (or automated linux-next builds) see an error, I
will fix it -- but by no chance I will spend my time compiling myself for
all the crazy architectures and configs for every patch that I apply.

But don't get me wrong, I am perfectly fine with actually testing the
patches on any weird arches -- if you are ready to lend me time on a ready
to use cloud-based automated build farm with all kinds of cross tools, I
will set up a 'testing' branch and will use it for compile-testing.

> > Now, with your patch:
> >
> > - Someone sends me a patch for goldfish driver;
> > - I starting to look for my cross-compilers collections, making all the
> >   environment setups, setting up a new build tree, looking for the
> >   outdated goldfish config, the ARM thing fails to build somewhere in
> >   arch/arm/plat-foo and drivers/mfd/bar. I become grumpy... and, you might
> >   not believe me, I open and edit drivers/power/Kconfig and remove
> 
> I am confused here.  If there are correct depends lines here in the Kconfig,
> then it _protects_ you from suffering like this.

No, if it says 'depends on FLUFFY_ARCH', it says that all that
'1%-users-fluffy-arch' must be buildable so that I could test the single
patch. Which is so often not true, the fluffy arches are quite often
broken. (Unlike x86, since we have tons of users for x86.)

So for me it is easier to remove the 'depends on FLUFFY_ARCH' and
compile-test it on x86, if that is possible (and in case of goldfish it is
surely possible).

> Yet, you want me to think
> that it adds new work, new cross compile requirements and so on.  I do
> not see how that can possibly happen.

Without additional 'depends on' I cover 99% of drivers, that is enough.
Again, I am not trying to be perfect.

> 
> >   needless 'depends on' (that is, I actually do these kind of things when
> >   I feel lazy enough).
> >
> > Do you agree that without the additional deps life is easier for me? :)
> 
> No, I do not agree.  In fact I see it as totally the opposite.  But I already
> said that I would not pursue this further, based only on differing points
> of view, and so, after sending this, I will adhere to that now.

I see. In that case, please feel free to send the patch to akpm with my
Nack and pointing to this discussion. If Andrew agrees and I was wrong
(and I'm really curious whether I am right or wrong), I will start
applying such patches in future.

Thanks,

Anton

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

[Geert Uytterhoeven]

On Thu, Feb 28, 2013 at 3:59 AM, Anton Vorontsov <anton@enomsg.org> wrote:
> On Wed, Feb 27, 2013 at 09:17:06PM -0500, Paul Gortmaker wrote:
> [...]
>> > Testing patches takes time, and if I have to do it for all bunch of
>> > different machines and architectures, it becomes mess and unmanageable. In
>>
>> So, you actually want my change then -- you do not want to test for
>> goldfish power issues unless goldfish is selected.  This is how I see
>> the situation.
>
> No, I want to cover as much as possible code in one go. This is not 'all
> or nothing' thing, plus I can't test whether the driver actually works,
> but testing that it compiles is a great deal, because quite often patches
> just don't compile. :-)

Indeed, I agree. I also want more build coverage.

BTW, sometimes I think our reviews are better in catching logical errors than
build/configuration errors. As soon as you fix the build, it just works ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Paul Gortmaker]

On 13-02-27 09:59 PM, Anton Vorontsov wrote:

[...]

> 
> I see. In that case, please feel free to send the patch to akpm with my
> Nack and pointing to this discussion. If Andrew agrees and I was wrong
> (and I'm really curious whether I am right or wrong), I will start
> applying such patches in future.

Hi Anton,

I didn't send the patch to akpm, but I did have a chance to ask akpm how
dependencies should be used, and you can see his answer here:

	https://lkml.org/lkml/2013/3/7/456

Paul.
--

> 
> Thanks,
> 
> Anton
> 

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

[Anton Vorontsov]

Hi Paul,

On Fri, Mar 08, 2013 at 11:38:41AM -0500, Paul Gortmaker wrote:
> > I see. In that case, please feel free to send the patch to akpm with my
> > Nack and pointing to this discussion. If Andrew agrees and I was wrong
> > (and I'm really curious whether I am right or wrong), I will start
> > applying such patches in future.
> 
> I didn't send the patch to akpm, but I did have a chance to ask akpm how
> dependencies should be used, and you can see his answer here:
> 
> 	https://lkml.org/lkml/2013/3/7/456

Thanks for asking! FWIW, I won't be against CONFIG_AKPM. ;-) Something
like that will work:

	depends on GENERIC_HARDIRQS
	depends on RESTRICT_PLATFORM && GOLDFISH

But not that I think we really need this option, though. Whoever wants to
(re)build the kernel is assumed to be knowledgeable enough to figure out
what needed/unneeded for the given HW. I, for example, use 'ARCH=foo
allnoconfig' for stripped kernels, and then enable specific options which
I know I will need. Distros, however, they are using kind of
'allmodconfig' anyways:

	~$ du -sh /lib/modules/3.8.0-28-desktop/
	148M    /lib/modules/3.8.0-28-desktop/

One module less, one module more does not matter, but maintaining
CONFIG_AKPM will cost devs' time and efforts (especially figuring out what
is platform dep and what is not... I think it is easier to just keep
things simple.

But again, I won't be against it -- at least it doesn't make my life
harder. :-)

Cheers,

Anton

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

[Paul Gortmaker]

On Fri, Mar 8, 2013 at 8:18 PM, Anton Vorontsov <anton@enomsg.org> wrote:
> Hi Paul,
>
> On Fri, Mar 08, 2013 at 11:38:41AM -0500, Paul Gortmaker wrote:
>> > I see. In that case, please feel free to send the patch to akpm with my
>> > Nack and pointing to this discussion. If Andrew agrees and I was wrong
>> > (and I'm really curious whether I am right or wrong), I will start
>> > applying such patches in future.
>>
>> I didn't send the patch to akpm, but I did have a chance to ask akpm how
>> dependencies should be used, and you can see his answer here:
>>
>>       https://lkml.org/lkml/2013/3/7/456
>
> Thanks for asking! FWIW, I won't be against CONFIG_AKPM. ;-) Something
> like that will work:
>
>         depends on GENERIC_HARDIRQS
>         depends on RESTRICT_PLATFORM && GOLDFISH
>
> But not that I think we really need this option, though. Whoever wants to

Of course, it was only meant sarcastically, but the CONFIG_AKPM
joke wasn't the important part of the email discussion though.

Above,  you asked "If Andrew agrees [that dependencies should describe
the hardware/platform] ... I will start applying such patches in future."

The important bit is Andrew's answer to your question:

  "...offering useless stuff to non-kernel-developers has downsides
  with no balancing benefit, and we really should optimise things
  for our users because there are so many more of them than there
  are of us."

That seems quite clear that we should be using dependencies to
properly describe the real system layout, and not offer up
useless stuff.  It is unclear to me how anyone could  interpret
it any different way -- i.e. GOLDFISH_POWER should depend on
GOLDFISH, just like the other GOLDFISH_XYZ options do now.

> (re)build the kernel is assumed to be knowledgeable enough to figure out
> what needed/unneeded for the given HW. I, for example, use 'ARCH=foo

This is another problem though -- as mentioned at kernel summit,
more people testing newer kernels is desired, but the barrier to entry
seems too high, and one of those barriers is Kconfig complexity.
Assuming everybody is "knowledgeable enough" does not match
reality.

Paul.
--

> allnoconfig' for stripped kernels, and then enable specific options which
> I know I will need. Distros, however, they are using kind of
> 'allmodconfig' anyways:
>
>         ~$ du -sh /lib/modules/3.8.0-28-desktop/
>         148M    /lib/modules/3.8.0-28-desktop/
>
> One module less, one module more does not matter, but maintaining
> CONFIG_AKPM will cost devs' time and efforts (especially figuring out what
> is platform dep and what is not... I think it is easier to just keep
> things simple.
>
> But again, I won't be against it -- at least it doesn't make my life
> harder. :-)
>
> Cheers,
>
> Anton
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

[Gene Heskett]

On Saturday 09 March 2013, Paul Gortmaker wrote:

I'd Cc: Paul's whole list, but it would bounce, so I'll post this where it 
will be seen.

>On Fri, Mar 8, 2013 at 8:18 PM, Anton Vorontsov <anton@enomsg.org> wrote:
>> Hi Paul,
>> 
>> On Fri, Mar 08, 2013 at 11:38:41AM -0500, Paul Gortmaker wrote:
>>> > I see. In that case, please feel free to send the patch to akpm with
>>> > my Nack and pointing to this discussion. If Andrew agrees and I was
>>> > wrong (and I'm really curious whether I am right or wrong), I will
>>> > start applying such patches in future.
>>> 
>>> I didn't send the patch to akpm, but I did have a chance to ask akpm
>>> how
>>> 
>>> dependencies should be used, and you can see his answer here:
>>>       https://lkml.org/lkml/2013/3/7/456
>> 
>> Thanks for asking! FWIW, I won't be against CONFIG_AKPM. ;-) Something
>> 
>> like that will work:
>>         depends on GENERIC_HARDIRQS
>>         depends on RESTRICT_PLATFORM && GOLDFISH
>> 
>> But not that I think we really need this option, though. Whoever wants
>> to
>
>Of course, it was only meant sarcastically, but the CONFIG_AKPM
>joke wasn't the important part of the email discussion though.
>
>Above,  you asked "If Andrew agrees [that dependencies should describe
>the hardware/platform] ... I will start applying such patches in future."
>
>The important bit is Andrew's answer to your question:
>
>  "...offering useless stuff to non-kernel-developers has downsides
>  with no balancing benefit, and we really should optimise things
>  for our users because there are so many more of them than there
>  are of us."
>
>That seems quite clear that we should be using dependencies to
>properly describe the real system layout, and not offer up
>useless stuff.  It is unclear to me how anyone could  interpret
>it any different way -- i.e. GOLDFISH_POWER should depend on
>GOLDFISH, just like the other GOLDFISH_XYZ options do now.
>
>> (re)build the kernel is assumed to be knowledgeable enough to figure
>> out what needed/unneeded for the given HW. I, for example, use
>> 'ARCH=foo
>
>This is another problem though -- as mentioned at kernel summit,
>more people testing newer kernels is desired, but the barrier to entry
>seems too high, and one of those barriers is Kconfig complexity.
>Assuming everybody is "knowledgeable enough" does not match
>reality.
>
>Paul.

I'll have to agree about the high barrier but you are placing the blame on 
Kconfig, whereas I place that blame squarely on 2 other points, first being 
the compiler speed, the 2nd, all the virtually undocumented changes to grub 
since about 2007.

When I built this 2.1 Ghz quad core 9550 phenom box with 4Gb of dram, I 
could build the then current kernel, using my own install script, the 
compiler version of that day, edit /boot/grub/grub.cfg and be rebooted to 
it in 20 minutes.

Same machine, fast fwd to 2 years ago, the start of my script to end of 
make modules phase was over 2 hours, and of course the install failed 
because the grub.cfg that counts no longer lives in /boot/grub, but is now 
buried in a directory in /etc.

Sure, I can fix my script to deal with the new grub I'd expect, but grubs 
new docs contain a 10-33 tor vacuum in terms of what this or that option 
really does, and what file to put that option in so its quasi-permanent for 
this kernel.  And taking 2, now probably over 3 hours to build the kernel 
of the week is patently excessive.  Your current compiler may be generating 
more precise code for my cpu, but its spinning its wheels at 2.1Ghz to get 
.5 kilohertz effective speed on my quad core phenom.  Seriously folks, WTH?

So I'm still here, lurking, but you have lost a tester when it takes 2 or 3 
hours to find out if it will even boot on a machine that was considered a 
server grade machine when it was new.  

I might add that it might have gotten 55 megs into swap in 2 weeks uptime 
then, now its 6days uptime and 326 megs into swap, needing a reboot as a 
swapoff -a;swapon -a will kill something important.  Like dbus for 
instance.

One former testers 2 cents.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
My views 
<http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml>
People don't usually make the same mistake twice -- they make it three
times, four time, five times...
I was taught to respect my elders, but its getting 
harder and harder to find any...

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

[Anton Vorontsov]

On Sat, Mar 09, 2013 at 10:49:08AM -0500, Paul Gortmaker wrote:
[...]
> >> I didn't send the patch to akpm, but I did have a chance to ask akpm how
> >> dependencies should be used, and you can see his answer here:
> >>
> >>       https://lkml.org/lkml/2013/3/7/456
> >
> > Thanks for asking! FWIW, I won't be against CONFIG_AKPM. ;-) Something
> > like that will work:
> >
> >         depends on GENERIC_HARDIRQS
> >         depends on RESTRICT_PLATFORM && GOLDFISH
> >
> > But not that I think we really need this option, though. Whoever wants to
> 
> Of course, it was only meant sarcastically, but the CONFIG_AKPM
> joke wasn't the important part of the email discussion though.
> 
> Above,  you asked "If Andrew agrees [that dependencies should describe
> the hardware/platform] ... I will start applying such patches in future."
> 
> The important bit is Andrew's answer to your question:
> 
>   "...offering useless stuff to non-kernel-developers has downsides
>   with no balancing benefit, and we really should optimise things
>   for our users because there are so many more of them than there
>   are of us."

To me, the important bit was "drives me bats when I merge a patch but have
to jump through a series of hoops ..."

And "we really should optimise things" does not mean that your patch is an
ideal solution. You make users' life a bit easier (maybe), but miserable
for me. As I read Andrew, a better solution have to be implemented (e.g.
CONFIG_AKPM, which I didn't find being too sarcastic :-), which would suit
both users and maintainers.

Btw, I am a Linux user too. And the amount of Kconfig symbols never ever
bothered me personally. Why? Look:

	~$ grep CONFIG /boot/config-3.8.0-28-desktop  | wc -l
	5274

Do you think that even if you divide this by two it would make any
difference? Not to me. When dealing with these large sets of options, my
strategy of making configs is different (as I explained previous emails it
is either '{old,allmod}config'+tuning or 'allnoconfig'+deliberately
enabling options for specific hardware/needs.

Don't take it personally, but for me the patch does not do anything good
at all. And again, feel free to send it to akpm with my nack and a link,
since I might be still wrong.

Cheers,

Anton