linux-kernel - Re: Ingo, no more kconfig patches

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: <20080503222943.GX5838@cs181133002.pp.htv.fi>
Date:	Sun, 4 May 2008 01:29:43 +0300
From:	Adrian Bunk <bunk@...nel.org>
To:	Krzysztof Halasa <khc@...waw.pl>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Ingo, no more kconfig patches

On Sun, May 04, 2008 at 12:13:29AM +0200, Krzysztof Halasa wrote:
> Adrian Bunk <bunk@...nel.org> writes:
> 
> > If you select LEDS_CLASS "select follows dependencies" would let inherit 
> > X86_RDC321X the dependencies of LEDS_CLASS,
> 
> I see, "follows" the other way around. That fixes the breakage but I
> guess it's not exactly what the people doing make menuconfig want.
> Though in absence of the following it would IMHO make sense anyway.

Kconfig is an interface for users.

>From a developer perspective if might be the easiest to simply remove 
the "select" syntax, but from an UI perspective it would be horrible.

> > And regarding "displaying all relevant dependency chains" to the user - 
> > I can't see how that would work in the more complicated cases.
> 
> I fear it too but perhaps there is some sane way? I don't know,
> asking (recursively?) interactively?
> 
> Like:
> QWERTY requires at least one, select (Y/M):
> - ARCH_X86 && NET_ETHERNET, or
> - USB4_0 && !SMP, or
> - XXX
> 
> then:
> NET_ETHERNET requires at lest one, select (Y/M):
> - PCI128
> - ISA256
> 
> then (info):
> PCI128 requires PCI and it's selected automatically.

FB_SGIVW requires X86_VISWS and it's selected automatically.

(which is not good if you want a kernel that runs on a PC)

> I don't know. It could be useful even with a single dependency when
> configuring as the module, the user could select Y or M for dependency
> interactively (people may want to have E1000E=m and TULIP=m but MII=y).

Why do we have to bother users with the MII option at all?

"E1000E=m and TULIP=m but MII=y" works, but it doesn't really make 
sense.

> Not sure if still on the same planet, though :-)
> -- 
> Krzysztof Halasa

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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