Re: NETPOLL=y , NETDEVICES=n compile error ( Re: 2.6.23-rc1-mm1 )

[Satyam Sharma <satyam@infradead.org>]

Hi,


On Thu, 2 Aug 2007, Sam Ravnborg wrote:

> > > 
> > > ...
> > > endif # NETDEVICES
> > > 
> > > config NETPOLL
> > >         depends on NETDEVICES
> > >         def_bool NETCONSOLE
> > > 
> > > config NETPOLL_TRAP
> > >         bool "Netpoll traffic trapping"
> > >         default n
> > >         depends on NETPOLL
> > > 
> > > config NET_POLL_CONTROLLER
> > >         def_bool NETPOLL
> > >         depends on NETPOLL
> > > 
> > > 
> > > seems to select NET_POLL_CONTROLLER after selecting NETPOLL, but
> > > still doesn't check for NETDEVICES dependency.
> > 
> > That's odd. Adding Sam to the cc:.

I just noticed this thread, but I wonder what the fuss is all
about :-) Kconfig dependencies are easy, really -- any code that
pulls in code from elsewhere, must explicitly "depends on" it.
It is possible to use "select" as well, but could lead to breakages
as discussed to death on at least 64592 other threads on LKML already
and hence should only be used for library-like code that does not
have any dependencies itself.


> select is evil....
> select will by brute force set a symbol equal to 'y' without
> visiting the dependencies.
> So abusing select you are able to select a symbol FOO even 
> if FOO depends on BAR that is not set.
> 
> In general use select only for non-visible symbols (no promts anywhere)
> and for symbols with no dependencies.
> That will limit the suefullness but on the other hand avoid the illegal
> configurations all over.

The problem with using "depends on" is that your config symbol becomes
invisible unless the dependency has already been selected.

So, there's a workaround: make the ultimate config symbol itself depend
upon the grand-dependency (excuse the nomenclature) and just "select"
the immediate-parent-dependency, i.e. the following:

CONFIG_BAZ
	...

CONFIG BAR
	depends on BAZ

CONFIG_FOO
	depends on BAZ
	select BAR

is perfectly legal, and doesn't cause any build problems. Perhaps such a
solution makes sense here as well?


> kconfig should one day warn about such things but I have not fel inclined
> to dive into the matters hoping that Roman does one day.

Yup, I've wanted to do this myself, in fact I wanted to implement an idea
I had in mind ( http://lkml.org/lkml/2007/5/16/257 ) but for some reason
I tend to stay away from stuff in scripts/ :-)


Satyam