From: Anton Vorontsov <anton@enomsg.org>
To: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: linux-kernel@vger.kernel.org, David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH] power: make goldfish option have a dependency on goldfish
Date: Sat, 9 Mar 2013 13:59:48 -0800 [thread overview]
Message-ID: <20130309215946.GA8386@lizard> (raw)
In-Reply-To: <CAP=VYLpxZzi6OFpDjJaR2EVcgmS4EcoAAk5wSzjrbi+QSfaEWw@mail.gmail.com>
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
prev parent reply other threads:[~2013-03-09 22:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-27 18:27 [PATCH] power: make goldfish option have a dependency on goldfish Paul Gortmaker
2013-02-27 23:18 ` Anton Vorontsov
2013-02-28 0:48 ` Paul Gortmaker
2013-02-28 1:35 ` Anton Vorontsov
2013-02-28 2:17 ` Paul Gortmaker
2013-02-28 2:59 ` Anton Vorontsov
2013-02-28 6:42 ` Geert Uytterhoeven
2013-03-08 16:38 ` Paul Gortmaker
2013-03-09 1:18 ` Anton Vorontsov
2013-03-09 15:49 ` Paul Gortmaker
2013-03-09 16:52 ` Gene Heskett
2013-03-09 21:59 ` Anton Vorontsov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130309215946.GA8386@lizard \
--to=anton@enomsg.org \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paul.gortmaker@windriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox