linux-kernel - Re: RFC: kconfig select warnings bogus?

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <a781481a0705200650v2ef7be85h19f8c8eb026a303b@mail.gmail.com>
Date:	Sun, 20 May 2007 19:20:25 +0530
From:	"Satyam Sharma" <satyam.sharma@...il.com>
To:	"Stefan Richter" <stefanr@...6.in-berlin.de>
Cc:	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Sam Ravnborg" <sam@...nborg.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"Roman Zippel" <zippel@...ux-m68k.org>,
	"Kumar Gala" <galak@...nel.crashing.org>,
	"Simon Horman" <horms@...ge.net.au>, "Adrian Bunk" <bunk@...sta.de>
Subject: Re: RFC: kconfig select warnings bogus?

On 5/20/07, Stefan Richter <stefanr@...6.in-berlin.de> wrote:
> Satyam Sharma wrote:
> > I was only answering your *completely misplaced and
> > incorrect* original comment against the patch where you claimed
> > that the patch was "totally wrong" because of the way it removed
> > the "select" ... etc ...
>
> I believe I have explained why I labeled it as totally wrong.

Because it is not "readable"? Umm, "*totally wrong*" is a pretty strong
comment to make just because _you_ find something less readable /
maintainable! Anyway, your initial post did give the impression that
you weren't aware of the "default y if ..." mechanism at all, and so
somehow thought the removal of select would cause some graver
problems because somehow the "dependency on XYZ which was
implied by select XYZ" had been lost by the removal of select ... etc.

> > And remember, like I said already, the whole _idea_ is such arch-
> > specific helper code be not mentioned from arch-agnostic Kconfig
> > files. You may not like it, but this is the standard / most common way
> > such cases are handled for tons of other cases in arch/...
>
> The standard and maintainable way (for drivers at least) is
>
> config A
>         bool-or-tristate "option A"
>         depends on !PLATFORM_X || HELPER_N_ON_PLATFORM_X

??? I didn't get this entry, can you give a solid example (you can consider
the case at hand, MOUSE_ATARI and ATARI_KBD_CORE itself). Better
still, if you really think that the above is a better way to solve the
problem at
hand, why don't you submit a patch instead?

> It is not a matter of me disliking something.  It's a matter of that we
> can easily determine what A needs, but have a hard time to determine and
> maintain the dependencies in the reverse way.
>
> BTW, if A needs platform-specific helper N, then A is not
> platform-agnostic.  If A is desired to be platform-agnostic, then either
> A has to be implemented independently of N or N has to be made available
> on all platforms.

What you are suggesting is not practically possible / convenient. See, we
_want_ MOUSE_ATARI to appear in the arch-agnostic area which is along
with the other input devices and hence it is placed in drivers/input/Kconfig.
However, it does depend on arch-specific helper code. This is a real issue,
and we can't simply wish it away.

> > Which is why Adrian's way of solving this (shifting all such
> > arch-specific helper symbols also to drivers/... and then using depends
> > on select on it) is not viable.
>
> I'm not advocating any specific fixes or pseudo-fixes.  I'm advocating
> the notation of dependencies in the direction "A requires B".

See, if you really _still_ think this could / should be done some better
way (which is more maintainable, does not cause build failures and
also does not cause those bogus warnings to be printed etc etc),
then please submit a patch instead.

> These things really should be shifted into the UIs as much as possible,
> because we can have a number of special-purpose UIs but we want
> all-purpose Kconfig files.

Well, the shortcomings of Kconfig / build scripts that you mentioned are
are somewhat valid indeed, but as I said, unless you or someone submits
patches to clear up the above issues, we do need to solve problems within
that framework itself, isn't it?

Thanks,
Satyam
-
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/