linux-kernel - Re: REGRESSION: Re: [GIT] kconfig rc fixes

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] [day] [month] [year] [list]

Message-ID: <20101105130205.68a4d781@endymion.delvare>
Date:	Fri, 5 Nov 2010 13:02:05 +0100
From:	Jean Delvare <khali@...ux-fr.org>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Michal Marek <mmarek@...e.cz>
Cc:	Arnaud Lacombe <lacombar@...il.com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	kyle@...hat.com, linux-kbuild@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Linux Media Mailing List <linux-media@...r.kernel.org>
Subject: Re: REGRESSION: Re: [GIT] kconfig rc fixes

On Thu, 04 Nov 2010 14:51:24 -0400, Mauro Carvalho Chehab wrote:
> Em 04-11-2010 14:32, Arnaud Lacombe escreveu:
> > Hi,
> > 
> > On Thu, Nov 4, 2010 at 2:11 PM, Mauro Carvalho Chehab
> > <mchehab@...hat.com> wrote:
> >> [...]
> >> Yes, but this makes things worse: it will allow compiling drivers that Kernel
> >> will never use, as they won't work without an I2C adapter, and the I2C adapter
> >> is not compiled.
> >>
> >> Worse than that: if you go into all V4L bridge drivers, that implements the I2C
> >> adapters and disable them, the I2C ancillary adapters will still be compiled
> >> (as they won't return to 'n'), but they will never ever be used...
> >>
> >> So, no, this is not a solution.
> >>
> >> What we need is to prompt the menu only if the user wants to do some manual configuration.
> >> Otherwise, just use the selects done by the drivers that implement the I2C bus adapters,
> >> and have some code to use those selected I2C devices.
> >>
> > These is an easy solution: doing as
> > `Documentation/kbuild/kconfig-language.txt' say it should be done:
> > 
> > config MODULES
> >         bool "modules ?"
> >         default y
> > 
> > config AUTO
> >         bool "AUTO"
> > 
> > config IVTV
> >         tristate "IVTV"
> >         select WM42 if AUTO
> > 
> > menu "TV"
> >         depends on !AUTO
> > 
> > config WM42_USER
> >         tristate "WM42"
> >         select WM42
> > 
> > endmenu
> > 
> > config WM42
> >         tristate
> >         default n
> > 
> >  - Arnaud
> 
> This may work, but it means that every single I2C/frontend/tuner will require two
> entries for each driver. This means to create and manage around 100+ new symbols.
> The drivers/media Kconfig files are complex enough as-is, without adding those 100+
> new artificial symbols. We should work to make things simple and improve users experience,
> and not to create artificial complexity that will make Kconfig almost unreadable.
> 
> I still think that the easiest way to solve this is to add some logic that will
> hide the menu if a condition doesn't happen. Something like:
> 	menu FOO
> 		prompt if BAR
> 
> or
> 	menu FOO
> 		show if BAR

I totally second Mauro's concerns and proposal. My own proposal was
along the lines of:

	menu FOO
		hide if BAR

but obviously the idea is the same, so it doesn't matter which of the 3
proposals gets implemented. The basic idea is to have a weak form of
"depends" for menus, which hides the menu from the user but preserves
all the symbols defines under that menu.

Michal, is the above something you would be able to implement in
Kconfig?

Thanks,
-- 
Jean Delvare
--
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/