On Tue, Jul 31, 2007 at 05:05:00PM +0200, Gabriel C wrote:
> Jarek Poplawski wrote:
> > On Tue, Jul 31, 2007 at 12:14:36PM +0200, Gabriel C wrote:
> >> Jarek Poplawski wrote:
> >>> On 28-07-2007 20:42, Gabriel C wrote:
> >>>> Andrew Morton wrote:
> >>>>> On Sat, 28 Jul 2007 17:44:45 +0200 Gabriel C <[email protected]> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I got this compile error with a randconfig ( http://194.231.229.228/MM/randconfig-auto-82.broken.netpoll.c ).
> >>>>>>
> >>>>>> ...
> >>>>>>
> >>>>>> net/core/netpoll.c: In function 'netpoll_poll':
> >>>>>> net/core/netpoll.c:155: error: 'struct net_device' has no member named 'poll_controller'
> >>>>>> net/core/netpoll.c:159: error: 'struct net_device' has no member named 'poll_controller'
> >>>>>> net/core/netpoll.c: In function 'netpoll_setup':
> >>>>>> net/core/netpoll.c:670: error: 'struct net_device' has no member named 'poll_controller'
> >>>>>> make[2]: *** [net/core/netpoll.o] Error 1
> >>>>>> make[1]: *** [net/core] Error 2
> >>>>>> make: *** [net] Error 2
> >>>>>> make: *** Waiting for unfinished jobs....
> >>>>>>
> >>>>>> ...
> >>>>>>
> >>>>>>
> >>>>>> I think is because KGDBOE selects just NETPOLL.
> >>>>>>
> >>>>> Looks like it.
> >>>>>
> >>>>> Select went and selected NETPOLL and NETPOLL_TRAP but things like
> >>>>> CONFIG_NETDEVICES and CONFIG_NET_POLL_CONTROLLER remain unset. `select'
> >>>>> remains evil.
> >>> ...
> >>>> I think there may be a logical issue ( again if I got it right ).
> >>>> We need some ethernet card to work with kgdboe right ? but we don't have any if !NETDEVICES && !NET_ETHERNET.
> >>>>
> >>>> So maybe some ' depends on ... && NETDEVICES!=n && NET_ETHERNET!=n ' is needed too ?
> >>> IMHO, the only logical issue here is netpoll.c mustn't use
> >>> CONFIG_NET_POLL_CONTROLLER code without #ifdef if it doesn't
> >>> add this dependency itself.
> >>>
> >> Well it does if NETDEVICES && if NET_ETHERNET which booth are N when !NETDEVICES is why KGDBOE uses select and not depends on.
> >
> > "does if XXX" means may "use if XXX".
>
> From what I know means only use "if xxx" on !xxx everything inside the "if xxx" is n and "depends on <something inside the if xxx>
> does not work.
>
> ...
>
> menuconfig FOO
> bool "FOO"
> depends on BAR
> default y
> -- help --
> something
> if FOO
>
> config BAZ
> depends on WHATEVR && !NOT_THIS
>
> menuconfig SOMETHING_ELSE
> ....
> if SOMETHING_ELSE
>
> config BLUBB
> depends on PCI && WHATNOT
>
> endif # SOMETHING_ELSE
>
> config NETPOLL
> def_bool NETCONSOLE
>
> config NETPOLL_TRAP
> bool "Netpoll traffic trapping"
> default n
> depends on NETPOLL
>
> config NET_POLL_CONTROLLER
> def_bool NETPOLL
>
> endif # FOO
>
> Now if you set FOO=n all is gone and your driver have to select whatever it needs from there.
Probably not exactly so...
>From drivers/net/Kconfig:
> # All the following symbols are dependent on NETDEVICES - do not repeat
> # that for each of the symbols.
> if NETDEVICES
So, according to this netpoll could presume NETDEVICES and
NET_POLL_CONTROLLER are always on.
But, as you've found, it's possible to select NETPOLL and !NETDEVICES,
so this comment is at least not precise.
On the other side something like this:
...
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.
>
> >
> >> Now KGDBOE just selects NETPOLL and NETPOLL_TRAP.
> >> Adding 'select CONFIG_NET_POLL_CONTROLLER' let kgdboe compiles but the question is does it work without any ethernet card ?
> >
> > Why kgdboe should care what netpoll needs? So, I hope, you are adding
> > this select under config NETPOLL. On the other hand, if NETPOLL should
> > depend on NET_POLL_CONTROLLER there is probably no reason to have them
> > both.
>
> NET_POLL_CONTROLLER has def_bool NETPOLL if NETDEVICES .
>
> Net peoples ping ?:)
OK, I wasn't right here: there is no visible reason for both in the
kernel code, but I can imagine there could be some external users of
NET_POLL_CONTROLLER without NETPOLL.
>
> >
> > The "does it work" question isn't logical issue, so it's irrelevant
> > here...
>
> Right irrelevant for the compile error but relevant for the fix in my opinion.
This was kind of joking, but since some people prefer things to work,
and it's hard to do this right (logical) way, some strange (unlogical)
measures have to be done like repeating dependencies here.
Regards,
Jarek P.
On Wed, Aug 01, 2007 at 11:59:21AM +0200, Jarek Poplawski wrote:
> On Tue, Jul 31, 2007 at 05:05:00PM +0200, Gabriel C wrote:
> > Jarek Poplawski wrote:
> > > On Tue, Jul 31, 2007 at 12:14:36PM +0200, Gabriel C wrote:
> > >> Jarek Poplawski wrote:
> > >>> On 28-07-2007 20:42, Gabriel C wrote:
> > >>>> Andrew Morton wrote:
> > >>>>> On Sat, 28 Jul 2007 17:44:45 +0200 Gabriel C <[email protected]> wrote:
> > >>>>>
> > >>>>>> Hi,
> > >>>>>>
> > >>>>>> I got this compile error with a randconfig ( http://194.231.229.228/MM/randconfig-auto-82.broken.netpoll.c ).
> > >>>>>>
> > >>>>>> ...
> > >>>>>>
> > >>>>>> net/core/netpoll.c: In function 'netpoll_poll':
> > >>>>>> net/core/netpoll.c:155: error: 'struct net_device' has no member named 'poll_controller'
> > >>>>>> net/core/netpoll.c:159: error: 'struct net_device' has no member named 'poll_controller'
> > >>>>>> net/core/netpoll.c: In function 'netpoll_setup':
> > >>>>>> net/core/netpoll.c:670: error: 'struct net_device' has no member named 'poll_controller'
> > >>>>>> make[2]: *** [net/core/netpoll.o] Error 1
> > >>>>>> make[1]: *** [net/core] Error 2
> > >>>>>> make: *** [net] Error 2
> > >>>>>> make: *** Waiting for unfinished jobs....
> > >>>>>>
> > >>>>>> ...
> > >>>>>>
> > >>>>>>
> > >>>>>> I think is because KGDBOE selects just NETPOLL.
> > >>>>>>
> > >>>>> Looks like it.
> > >>>>>
> > >>>>> Select went and selected NETPOLL and NETPOLL_TRAP but things like
> > >>>>> CONFIG_NETDEVICES and CONFIG_NET_POLL_CONTROLLER remain unset. `select'
> > >>>>> remains evil.
> > >>> ...
> > >>>> I think there may be a logical issue ( again if I got it right ).
> > >>>> We need some ethernet card to work with kgdboe right ? but we don't have any if !NETDEVICES && !NET_ETHERNET.
> > >>>>
> > >>>> So maybe some ' depends on ... && NETDEVICES!=n && NET_ETHERNET!=n ' is needed too ?
> > >>> IMHO, the only logical issue here is netpoll.c mustn't use
> > >>> CONFIG_NET_POLL_CONTROLLER code without #ifdef if it doesn't
> > >>> add this dependency itself.
> > >>>
> > >> Well it does if NETDEVICES && if NET_ETHERNET which booth are N when !NETDEVICES is why KGDBOE uses select and not depends on.
> > >
> > > "does if XXX" means may "use if XXX".
> >
> > From what I know means only use "if xxx" on !xxx everything inside the "if xxx" is n and "depends on <something inside the if xxx>
> > does not work.
> >
> > ...
> >
> > menuconfig FOO
> > bool "FOO"
> > depends on BAR
> > default y
> > -- help --
> > something
> > if FOO
> >
> > config BAZ
> > depends on WHATEVR && !NOT_THIS
> >
> > menuconfig SOMETHING_ELSE
> > ....
> > if SOMETHING_ELSE
> >
> > config BLUBB
> > depends on PCI && WHATNOT
> >
> > endif # SOMETHING_ELSE
> >
> > config NETPOLL
> > def_bool NETCONSOLE
> >
> > config NETPOLL_TRAP
> > bool "Netpoll traffic trapping"
> > default n
> > depends on NETPOLL
> >
> > config NET_POLL_CONTROLLER
> > def_bool NETPOLL
> >
> > endif # FOO
> >
> > Now if you set FOO=n all is gone and your driver have to select whatever it needs from there.
>
> Probably not exactly so...
>
> >From drivers/net/Kconfig:
>
> > # All the following symbols are dependent on NETDEVICES - do not repeat
> > # that for each of the symbols.
> > if NETDEVICES
>
> So, according to this netpoll could presume NETDEVICES and
> NET_POLL_CONTROLLER are always on.
>
> But, as you've found, it's possible to select NETPOLL and !NETDEVICES,
> so this comment is at least not precise.
>
> On the other side something like this:
>
> ...
> 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:.
> > >> Now KGDBOE just selects NETPOLL and NETPOLL_TRAP.
> > >> Adding 'select CONFIG_NET_POLL_CONTROLLER' let kgdboe compiles but the question is does it work without any ethernet card ?
> > >
> > > Why kgdboe should care what netpoll needs? So, I hope, you are adding
> > > this select under config NETPOLL. On the other hand, if NETPOLL should
> > > depend on NET_POLL_CONTROLLER there is probably no reason to have them
> > > both.
> >
> > NET_POLL_CONTROLLER has def_bool NETPOLL if NETDEVICES .
> >
> > Net peoples ping ?:)
How about cc:ing the netpoll maintainer?
> OK, I wasn't right here: there is no visible reason for both in the
> kernel code, but I can imagine there could be some external users of
> NET_POLL_CONTROLLER without NETPOLL.
I don't know of any. As far as I can tell at this point,
NET_POLL_CONTROLLER == NETPOLL.
--
Mathematics is the supreme nostalgia of our time.
On Wed, Aug 01, 2007 at 09:02:19PM -0500, Matt Mackall wrote:
> On Wed, Aug 01, 2007 at 11:59:21AM +0200, Jarek Poplawski wrote:
> > On Tue, Jul 31, 2007 at 05:05:00PM +0200, Gabriel C wrote:
> > > Jarek Poplawski wrote:
> > > > On Tue, Jul 31, 2007 at 12:14:36PM +0200, Gabriel C wrote:
> > > >> Jarek Poplawski wrote:
> > > >>> On 28-07-2007 20:42, Gabriel C wrote:
> > > >>>> Andrew Morton wrote:
> > > >>>>> On Sat, 28 Jul 2007 17:44:45 +0200 Gabriel C <[email protected]> wrote:
...
> > > >>>>>> net/core/netpoll.c:155: error: 'struct net_device' has no member named 'poll_controller'
...
> > > >>>>>> I think is because KGDBOE selects just NETPOLL.
> > > >>>>>>
> > > >>>>> Looks like it.
> > > >>>>>
> > > >>>>> Select went and selected NETPOLL and NETPOLL_TRAP but things like
> > > >>>>> CONFIG_NETDEVICES and CONFIG_NET_POLL_CONTROLLER remain unset. `select'
> > > >>>>> remains evil.
...
> > 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:.
Looks right, but after reading Andrew's opinion about select I'd be
astonished if he doesn't know this problem already.
>
> > > >> Now KGDBOE just selects NETPOLL and NETPOLL_TRAP.
> > > >> Adding 'select CONFIG_NET_POLL_CONTROLLER' let kgdboe compiles but the question is does it work without any ethernet card ?
> > > >
> > > > Why kgdboe should care what netpoll needs? So, I hope, you are adding
> > > > this select under config NETPOLL. On the other hand, if NETPOLL should
> > > > depend on NET_POLL_CONTROLLER there is probably no reason to have them
> > > > both.
> > >
> > > NET_POLL_CONTROLLER has def_bool NETPOLL if NETDEVICES .
> > >
> > > Net peoples ping ?:)
>
> How about cc:ing the netpoll maintainer?
Is there a new one or do you suggest possibility of abusing the
authority of the netpoll's author with such trifles...?!
BTW, I can't find any official meaning of def_bool, but it's name
suggests only default value, so logically it should be not enough
to assure NET_POLL_CONTROLLER=y, and netpoll should use "depends",
"require" or "select" (IMHO more readable too), but on the other
hand this could be practially wrong...
>
> > OK, I wasn't right here: there is no visible reason for both in the
> > kernel code, but I can imagine there could be some external users of
> > NET_POLL_CONTROLLER without NETPOLL.
>
> I don't know of any. As far as I can tell at this point,
> NET_POLL_CONTROLLER == NETPOLL.
There are some notions about "other diagnostic tools" in some
net drivers, eg. 3c509.c, so there would be a little bit of
work if, after changing this, they really exist (and even if
not - maybe it's reasonable to save such possibility for the
future?).
Best regards,
Jarek P.
> >
> > ...
> > 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:.
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.
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.
Sam
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
[ Read through the thread, looked at Kconfig files,
did some tests. Adding Kconfig experts to Cc: list. ]
> 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
Gargh, what we're seeing here is a whole bunch of bugs, I think. First
I thought this must be one of those randconfig-producing-wrong-configs
issues, but surprisingly, running "make oldconfig" on this .config on
a fresh 2.6.23-rc1-mm1 tree didn't change anything in the .config.
Kconfig bug #1:
===============
Which means, although:
*****
menuconfig BAZ
if BAZ
config BAR
endif
*****
is widely believed (by most folks, I've heard this on several threads,
and as written in the comment in drivers/net/Kconfig) to be equivalent to:
*****
menuconfig BAZ
if BAZ
endif
config BAR
depends on BAZ
*****
this is *not* enforced by "make oldconfig"! And hence, the NETPOLL &&
!NETDEVICES situation we're seeing here.
[ We could also categorize this as a bug in Kconfig's "if", fwiw. ]
Kconfig bug #2:
===============
config FOO
def_bool BAR
is supposed to ensure that FOO == BAR (as Matt mentioned earlier).
However, even this is *not* enforced by "make oldconfig". And hence,
the NETPOLL && !NET_POLL_CONTROLLER situation we're seeing here.
In fact, I believe it's possible to even pass a NETCONSOLE but
!NETPOLL kind of .config through "make oldconfig" but it still won't
catch it, and build breakages *will* occur.
[ We could also categorize this as a bug in Kconfig's "def_bool", fwiw. ]
Possibly, we could also decide to just blame "randconfig" for the whole
issue, and forget about these, because I think it's highly unlikely
(though not impossible) for people with "real" .configs to hit the
problems we saw above.
KGDBOE bug #1:
==============
config KGDBOE in lib/Kconfig.kgdb must also "depend on" NETDEVICES,
and select NET_POLL_CONTROLLER also.
KGDBOE bug #2:
==============
config KGDBOE_NOMODULE is a sad, sad option, and must be killed. The
"if !KGDBOE_NOMODULE" in KGDBOE must be removed, and it must lose its
dependency on "m".
Satyam
On Thu, Aug 02, 2007 at 04:02:21PM +0530, Satyam Sharma wrote:
> 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.
So, it seems at least one time not enough (or maybe it would be better
to write this 1 time only, but in Documentation/).
>
>
> > 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/ :-)
How often "common" developer has to make such decisions in Kconfig?
Probably no more than once per year. So, it's fair to blame anybody
for not reading lkml to find if there are some bugs or
recommendations before using apparently simple tool? I think there
is usually some README for such things (maybe in Documentation/)?
Thanks,
Jarek P.
PS: if it's so easy and it's enough to read only 64592 lkml messages,
I wonder why Andrew, who knows all lkml, and reads more messages per
hour, cared to remember mainly one short conclusion...
On Thu, 2 Aug 2007, Jarek Poplawski wrote:
> On Thu, Aug 02, 2007 at 04:02:21PM +0530, Satyam Sharma wrote:
> [...]
> How often "common" developer has to make such decisions in Kconfig?
> Probably no more than once per year. So, it's fair to blame anybody
> for not reading lkml to find if there are some bugs or
> recommendations before using apparently simple tool? I think there
> is usually some README for such things (maybe in Documentation/)?
Whoops, I only said that in humour, probably should've snuck in a
smiley or two. Definitely not blaming anybody. Apologies to anyone
who felt offended, sorry, nothing such was intended, I assure.
Satyam
On Thu, Aug 02, 2007 at 05:26:12PM +0530, Satyam Sharma wrote:
...
> Whoops, I only said that in humour, probably should've snuck in a
> smiley or two. Definitely not blaming anybody. Apologies to anyone
> who felt offended, sorry, nothing such was intended, I assure.
I see you probably didn't notice my smileys too. I need them so often
that I've to abbreviate them with something like this: ",.?!"
But, I'm also sorry if you felt confused I felt offended etc...
Jarek P.
On Thu, Aug 02, 2007 at 11:00:08AM +0200, Jarek Poplawski wrote:
> On Wed, Aug 01, 2007 at 09:02:19PM -0500, Matt Mackall wrote:
> > On Wed, Aug 01, 2007 at 11:59:21AM +0200, Jarek Poplawski wrote:
> > > On Tue, Jul 31, 2007 at 05:05:00PM +0200, Gabriel C wrote:
> > > > Jarek Poplawski wrote:
> > > > > On Tue, Jul 31, 2007 at 12:14:36PM +0200, Gabriel C wrote:
> > > > >> Jarek Poplawski wrote:
> > > > >>> On 28-07-2007 20:42, Gabriel C wrote:
> > > > >>>> Andrew Morton wrote:
> > > > >>>>> On Sat, 28 Jul 2007 17:44:45 +0200 Gabriel C <[email protected]> wrote:
> ...
> > > > >>>>>> net/core/netpoll.c:155: error: 'struct net_device' has no member named 'poll_controller'
> ...
> > > > >>>>>> I think is because KGDBOE selects just NETPOLL.
> > > > >>>>>>
> > > > >>>>> Looks like it.
> > > > >>>>>
> > > > >>>>> Select went and selected NETPOLL and NETPOLL_TRAP but things like
> > > > >>>>> CONFIG_NETDEVICES and CONFIG_NET_POLL_CONTROLLER remain unset. `select'
> > > > >>>>> remains evil.
> ...
> > > 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:.
>
> Looks right, but after reading Andrew's opinion about select I'd be
> astonished if he doesn't know this problem already.
>
> >
> > > > >> Now KGDBOE just selects NETPOLL and NETPOLL_TRAP.
> > > > >> Adding 'select CONFIG_NET_POLL_CONTROLLER' let kgdboe compiles but the question is does it work without any ethernet card ?
> > > > >
> > > > > Why kgdboe should care what netpoll needs? So, I hope, you are adding
> > > > > this select under config NETPOLL. On the other hand, if NETPOLL should
> > > > > depend on NET_POLL_CONTROLLER there is probably no reason to have them
> > > > > both.
> > > >
> > > > NET_POLL_CONTROLLER has def_bool NETPOLL if NETDEVICES .
> > > >
> > > > Net peoples ping ?:)
> >
> > How about cc:ing the netpoll maintainer?
>
> Is there a new one or do you suggest possibility of abusing the
> authority of the netpoll's author with such trifles...?!
I'm just subtly suggesting that if you're going to have a discussion
about netpoll, you ought to cc: me.
> There are some notions about "other diagnostic tools" in some
> net drivers, eg. 3c509.c, so there would be a little bit of
> work if, after changing this, they really exist (and even if
> not - maybe it's reasonable to save such possibility for the
> future?).
I created it for netpoll, only netpoll clients have ever cared.
--
Mathematics is the supreme nostalgia of our time.
On Thu, Aug 02, 2007 at 10:59:23AM -0500, Matt Mackall wrote:
> On Thu, Aug 02, 2007 at 11:00:08AM +0200, Jarek Poplawski wrote:
> > On Wed, Aug 01, 2007 at 09:02:19PM -0500, Matt Mackall wrote:
...
> > > How about cc:ing the netpoll maintainer?
> >
> > Is there a new one or do you suggest possibility of abusing the
> > authority of the netpoll's author with such trifles...?!
>
> I'm just subtly suggesting that if you're going to have a discussion
> about netpoll, you ought to cc: me.
Thanks! I'm very honored. I've suspected there is some subtlety, but
wasn't sure of possible new patches to MAINTAINERS, so tried to be
subtle too...
>
> > There are some notions about "other diagnostic tools" in some
> > net drivers, eg. 3c509.c, so there would be a little bit of
> > work if, after changing this, they really exist (and even if
> > not - maybe it's reasonable to save such possibility for the
> > future?).
>
> I created it for netpoll, only netpoll clients have ever cared.
So, probably you're the best person to change this! Alas, it seems,
for some time any changes to netpoll could have a cold reception
here (pity for Ingo's laptop...).
Regards,
Jarek P.
Hi,
If there are no other plans of kconfig docs update I think this
message of yours should be useful enough. I made minimal fixes,
so if they are wrong or you prefer it otherwise, I'm OK with any
change to this proposal, including replacement with something
else.
Thanks & regards,
Jarek P.
On Thu, Aug 02, 2007 at 11:36:59AM +0200, Sam Ravnborg wrote:
...
> > > 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:.
>
> 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.
>
> 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.
>
> Sam
>
----------->
Subject: docs: a warning note about select in kconfig-language.txt
A warning note of Sam Ravnborg about kconfig's select evilness,
dependencies and the future (slightly corrected).
Signed-off-by: Jarek Poplawski <[email protected]>
Cc: Sam Ravnborg <[email protected]>
---
diff -Nu9r 2.6.23-rc1-/Documentation/kbuild/kconfig-language.txt 2.6.23-rc1/Documentation/kbuild/kconfig-language.txt
--- 2.6.23-rc1-/Documentation/kbuild/kconfig-language.txt 2007-07-09 01:32:17.000000000 +0200
+++ 2.6.23-rc1/Documentation/kbuild/kconfig-language.txt 2007-08-06 12:50:34.000000000 +0200
@@ -92,18 +92,27 @@
- reverse dependencies: "select" <symbol> ["if" <expr>]
While normal dependencies reduce the upper limit of a symbol (see
below), reverse dependencies can be used to force a lower limit of
another symbol. The value of the current menu symbol is used as the
minimal value <symbol> can be set to. If <symbol> is selected multiple
times, the limit is set to the largest selection.
Reverse dependencies can only be used with boolean or tristate
symbols.
+ Note:
+ 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 usefulness but on the
+ other hand avoid the illegal configurations all over. kconfig
+ should one day warn about such things.
- numerical ranges: "range" <symbol> <symbol> ["if" <expr>]
This allows to limit the range of possible input values for int
and hex symbols. The user can only input a value which is larger than
or equal to the first symbol and smaller than or equal to the second
symbol.
- help text: "help" or "---help---"
This defines a help text. The end of the help text is determined by