From: Adrian Bunk <hidden> Date: 2005-11-16 23:58:14
On Thu, Nov 17, 2005 at 12:10:17AM +0100, Christian wrote:
hi,
i noticed that some of my QoS rules are not working any more. oh, i
forgot to enable CONFIG_NET_CLS_U32. but when enabled, i got the
following errors when compiling / installing the module:
* Warning: "unregister_tcf_proto_ops" [net/sched/cls_u32.ko] undefined!
* Warning: "register_tcf_proto_ops" [net/sched/cls_u32.ko] undefined!
* Warning: "tcf_exts_dump" [net/sched/cls_u32.ko] undefined!
* Warning: "tcf_exts_dump_stats" [net/sched/cls_u32.ko] undefined!
* Warning: "tcf_exts_change" [net/sched/cls_u32.ko] undefined!
* Warning: "tcf_exts_validate" [net/sched/cls_u32.ko] undefined!
* Warning: "tcf_exts_destroy" [net/sched/cls_u32.ko] undefined!
...
when i disabled CONFIG_NET_CLS_U32, everything compiles fine, but
cls_u32 is missing of course :-(
all the missing symbols seem to be defined in include/net/pkt_cls.h. but
this file is #included by net/sched/cls_u32.c and other too, so i
don't really know, why it doesn't work.
FWIW, i see EXPORT_SYMBOLs at the very end of net/sched/cls_api.c, but i
can't see if/when cls_api.c is used (included?) at all.
...
I'm assuming you are trying to insert the new module in your old kernel?
This is one of the unfortunate but hardly avoidable cases where adding a
module requires installing a new kernel.
But there's a change in 2.6.15-rc1 that makes this issue much worse:
It is no longer user-visible.
tristate's select'ing bool's that do not change parts of the (modular)
driver but compile additional code into the kernel are simply wrong.
thanks for looking into that,
Christian.
...
cu
Adrian
BTW: Please Cc netdev@vger.kernel.org on networking issues.
--
"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
From: Christian <hidden> Date: 2005-11-17 00:07:53
Adrian Bunk schrieb:
I'm assuming you are trying to insert the new module in your old kernel?
yes, i tried to "modprobe" the compiled cls_u32 module. but the "make
modules" errors are there anyway. i tried to compile a fresh 2.6.15-rc1
on a different machine (where i can't do "modprobe") and the errors were
there too: http://nerdbynature.de/bits/sheep/2.6.15-rc1/make-modules.log
This is one of the unfortunate but hardly avoidable cases where adding a
module requires installing a new kernel.
despite of the errors on "make modules" i'll reboot with the "new"
kernel asap.
BTW: Please Cc netdev@vger.kernel.org on networking issues.
ok, will do that.
thank you,
Christian.
--
BOFH excuse #442:
Trojan horse ran out of hay
From: Christian <hidden> Date: 2005-11-17 15:58:26
Christian schrieb:
Adrian Bunk schrieb:
quoted
I'm assuming you are trying to insert the new module in your old kernel?
yes, rebuilding the whole kernel (after just enabling NET_CLS_U32 as a
module) makes the warnings go away.
quoted
This is one of the unfortunate but hardly avoidable cases where adding
a module requires installing a new kernel.
i wonder why/if this is really needed. although not critical, this
behaviour is pretty annoying....
thanks,
Christian.
--
BOFH excuse #24:
network packets travelling uphill (use a carrier pigeon)
From: Adrian Bunk <hidden> Date: 2005-11-21 15:59:57
...
But there's a change in 2.6.15-rc1 that makes this issue much worse:
It is no longer user-visible.
tristate's select'ing bool's that do not change parts of the (modular)
driver but compile additional code into the kernel are simply wrong.
The patch below (should apply against 2.6.15-rc2) fixes this issue.
cu
Adrian
<-- snip -->
2.6.15-rc changes NET_CLS to being automatically select'ed when needed.
This patch confuses users since NET_CLS is a bool, and compiling an
additional module that select's NET_CLS causes unresolved symbols since
it's not user-visible that adding a module changes the kernel image.
This patch therefore changes NET_CLS back to the 2.6.14 status quo of
being an user-visible option.
Signed-off-by: Adrian Bunk <redacted>
---
net/sched/Kconfig | 25 ++++++++++++++++---------
1 file changed, 16 insertions(+), 9 deletions(-)
From: Patrick McHardy <hidden> Date: 2005-11-21 16:16:43
Adrian Bunk wrote:
2.6.15-rc changes NET_CLS to being automatically select'ed when needed.
This patch confuses users since NET_CLS is a bool, and compiling an
additional module that select's NET_CLS causes unresolved symbols since
it's not user-visible that adding a module changes the kernel image.
This patch therefore changes NET_CLS back to the 2.6.14 status quo of
being an user-visible option.
I disagree with this patch. NET_CLS enables the infrastructure support
for classifiers. Users generally don't care about infrastructure but
directly usable things, so I'd prefer to have it automatically selected.
And there are lots of other cases where enabling a module causes changes
in the kernel image. Some examples include some of the netfilter stuff,
the IPsec transforms, NET_CLS_ROUTE4, the ieee80211 stuff, and a lot
more.
From: "David S. Miller" <davem@davemloft.net> Date: 2005-11-22 22:37:14
From: Patrick McHardy <redacted>
Date: Mon, 21 Nov 2005 17:16:18 +0100
Adrian Bunk wrote:
quoted
This patch therefore changes NET_CLS back to the 2.6.14 status quo of
being an user-visible option.
I disagree with this patch. NET_CLS enables the infrastructure support
for classifiers. Users generally don't care about infrastructure but
directly usable things, so I'd prefer to have it automatically selected.
And there are lots of other cases where enabling a module causes changes
in the kernel image. Some examples include some of the netfilter stuff,
the IPsec transforms, NET_CLS_ROUTE4, the ieee80211 stuff, and a lot
more.
I agree with Patrick.
Changing config options of any kind can result in the main kernel
image needing to be rebuilt. One thing we can do to prevent human
mistakes, is to make the "make modules" pass do a quick "is vmlinux
uptodate?" check, and if not print out an error message explaining the
situation and aborting the "make modules" attempt.
From: Sam Ravnborg <hidden> Date: 2005-11-22 22:49:08
On Tue, Nov 22, 2005 at 02:37:13PM -0800, David S. Miller wrote:
One thing we can do to prevent human
mistakes, is to make the "make modules" pass do a quick "is vmlinux
uptodate?" check, and if not print out an error message explaining the
situation and aborting the "make modules" attempt.
I do not quite follow you here.
For a while I have considered implementing something that told why a
given file was compiled - like:
CC net/ipv4/ip_gre.o due to net/dsfield.h, net/xfrm.h
CC net/ipv4/raw.c due to include/config/ip/mroute.h
The latter is a config option that I do not see a possibility to change
back to a config option syntax (at least not without doing some effort).
My thinking was that 'make V=2' would give above printout.
But what you request is something that keep the dense printout without
building the kernel - right?
Any suggestion for an intuitive syntax to enable that?
'make -n V=2' will not do it.
Sam
From: "David S. Miller" <davem@davemloft.net> Date: 2005-11-22 23:00:23
From: Sam Ravnborg <redacted>
Date: Tue, 22 Nov 2005 23:49:14 +0100
On Tue, Nov 22, 2005 at 02:37:13PM -0800, David S. Miller wrote:
quoted
One thing we can do to prevent human
mistakes, is to make the "make modules" pass do a quick "is vmlinux
uptodate?" check, and if not print out an error message explaining the
situation and aborting the "make modules" attempt.
I do not quite follow you here.
If the user tries to do a "make modules" without first rebuilding
their kernel image, then the make will fail if the dependencies
are not satisfied for the main kernel image and it is thus not
up to date.
From: Adrian Bunk <hidden> Date: 2005-11-22 23:12:42
On Tue, Nov 22, 2005 at 02:37:13PM -0800, David S. Miller wrote:
...
Changing config options of any kind can result in the main kernel
image needing to be rebuilt. One thing we can do to prevent human
mistakes, is to make the "make modules" pass do a quick "is vmlinux
uptodate?" check, and if not print out an error message explaining the
situation and aborting the "make modules" attempt.
This won't work with CONFIG_IKCONFIG=y.
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
From: Sam Ravnborg <hidden> Date: 2005-11-23 05:57:27
On Tue, Nov 22, 2005 at 03:00:41PM -0800, David S. Miller wrote:
From: Sam Ravnborg <redacted>
Date: Tue, 22 Nov 2005 23:49:14 +0100
quoted
On Tue, Nov 22, 2005 at 02:37:13PM -0800, David S. Miller wrote:
quoted
One thing we can do to prevent human
mistakes, is to make the "make modules" pass do a quick "is vmlinux
uptodate?" check, and if not print out an error message explaining the
situation and aborting the "make modules" attempt.
I do not quite follow you here.
If the user tries to do a "make modules" without first rebuilding
their kernel image, then the make will fail if the dependencies
are not satisfied for the main kernel image and it is thus not
up to date.
OK - so a simple 'make -q vmlinux' check, except that the way we utilise
make will let it fail at first build command.
That will obscufate things even more in kbuild - but I will give it a
try sometime. It will be easy to cover 95% but to reach 100%
predictability will be though.
- file dependencies is easy
- command line changes is relatively easy
- but the various scripts and user commands will be tricky..
Not on the top of the TODO list though.
Sam
From: Thomas Graf <tgraf@suug.ch> Date: 2005-11-23 10:26:51
* David S. Miller [off-list ref] 2005-11-22 14:37
From: Patrick McHardy <redacted>
Date: Mon, 21 Nov 2005 17:16:18 +0100
quoted
Adrian Bunk wrote:
quoted
This patch therefore changes NET_CLS back to the 2.6.14 status quo of
being an user-visible option.
I disagree with this patch. NET_CLS enables the infrastructure support
for classifiers. Users generally don't care about infrastructure but
directly usable things, so I'd prefer to have it automatically selected.
And there are lots of other cases where enabling a module causes changes
in the kernel image. Some examples include some of the netfilter stuff,
the IPsec transforms, NET_CLS_ROUTE4, the ieee80211 stuff, and a lot
more.
I agree with Patrick.
In fact Patrick's explanation was exactly the motivation for me to
change it in the first place a few weeks back.
I thought about making cls_api aware to be built as module but then
the same would apply for ematches and the generic scheduling code
and it gets real complicated. It is possible with some heavy code
shuffling but not worth it I think.
On Wed, 23 Nov 2005 06:57:35 +0100 Sam Ravnborg wrote:
On Tue, Nov 22, 2005 at 03:00:41PM -0800, David S. Miller wrote:
quoted
From: Sam Ravnborg <redacted>
Date: Tue, 22 Nov 2005 23:49:14 +0100
quoted
On Tue, Nov 22, 2005 at 02:37:13PM -0800, David S. Miller wrote:
quoted
One thing we can do to prevent human
mistakes, is to make the "make modules" pass do a quick "is vmlinux
uptodate?" check, and if not print out an error message explaining the
situation and aborting the "make modules" attempt.
I do not quite follow you here.
If the user tries to do a "make modules" without first rebuilding
their kernel image, then the make will fail if the dependencies
are not satisfied for the main kernel image and it is thus not
up to date.
OK - so a simple 'make -q vmlinux' check, except that the way we utilise
make will let it fail at first build command.
That will obscufate things even more in kbuild - but I will give it a
try sometime. It will be easy to cover 95% but to reach 100%
predictability will be though.
- file dependencies is easy
- command line changes is relatively easy
- but the various scripts and user commands will be tricky..
Not on the top of the TODO list though.
So -q means "quick" ?
I wouldn't mind seeing a -quiet (even less quiet than V=0),
not even printing the CC, AS, LD, etc. commands -- just let the
tools print errors & warnings. I always redirect output to a
disk file and filter it for errors and warnings anyway, so I
want hold my breath for this, but ISTM that V=0 could be even
quieter than it is right now.
---
~Randy
From: Sam Ravnborg <hidden> Date: 2005-11-24 05:40:05
On Wed, Nov 23, 2005 at 06:13:32PM -0800, Randy.Dunlap wrote:
So -q means "quick" ?
From make help:
-q, --question Run no commands; exit status says if up to date
I wouldn't mind seeing a -quiet (even less quiet than V=0),
not even printing the CC, AS, LD, etc. commands -- just let the
tools print errors & warnings. I always redirect output to a
disk file and filter it for errors and warnings anyway, so I
want hold my breath for this, but ISTM that V=0 could be even
quieter than it is right now.
make -s shuld give you this. I've not used it for long though...
Sam