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

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20130309215946.GA8386@lizard>
Date:	Sat, 9 Mar 2013 13:59:48 -0800
From:	Anton Vorontsov <anton@...msg.org>
To:	Paul Gortmaker <paul.gortmaker@...driver.com>
Cc:	linux-kernel@...r.kernel.org, David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH] power: make goldfish option have a dependency on goldfish

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
--
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/