bug in /net/core/dev.c
Hi Keith,
This is a cure the syntom not the problem, build order shouldn't mess up something this simple.
I've forwarded your patch to Ulrich & Martin ( the s390 maintainers ) & they may use it
seeing as you & possibly others would prefer a /drivers/net/s390. David admitted it is a bug, if the patch is good hopefully it will be taken,
it if better can be done hopefully someone will do better.
D.J. Barrow Gnu/Linux for S/390 kernel developer
eMail: [email protected],[email protected]
Phone: +49-(0)7031-16-2583
IBM Germany Lab, Schönaicherstr. 220, 71032 Böblingen
Keith Owens <[email protected]> on 12.06.2001 18:11:26
Please respond to Keith Owens <[email protected]>
To: "David S. Miller" <[email protected]>
cc: Denis Joseph Barrow/Germany/Contr/IBM@IBMDE,
[email protected], [email protected]
Subject: Re: bug in /net/core/dev.c
Quoted 6 lines · David S. Miller
So, if the s390 folks move their stuff into the appropriate spot it will work. In fact, I personally like to see the s390 net devices under
drivers/net/s390anyways. They'll get free maintenance from myself and Jeff Garzik in this way as I rarely look intdrivers/${PLATFORM}type directories unless I'm doing a tree-wide grep. :-)
Leave s390 separate for the moment, all the other architectures work the same way.
Minimal (and totally untested) patch to compile s390/net as part of the other network drivers follows - if it's good enough for acorn, it's good enough for s390. The method is as ugly as hell but it is the least possible change for 2.4, major redesign will have to wait for 2.5. Patch against 2.4.6-pre2.
Index: 6-pre2.1/drivers/s390/Makefile
--- 6-pre2.1/drivers/s390/Makefile Fri, 13 Apr 2001 12:02:38 +1000 kaos (linux-2.4/u/b/43_Makefile 1.3 644)
+++ 6-pre2.1(w)/drivers/s390/Makefile Wed, 13 Jun 2001 02:05:24 +1000 kaos (linux-2.4/u/b/43_Makefile 1.3 644)
@@ -4,7 +4,7 @@
O_TARGET := io.o
-subdir-y := block char misc net
+subdir-y := block char misc
subdir-m := $(subdir-y)
obj-y := $(foreach dir,$(subdir-y),$(dir)/s390-$(dir).o)
@@ -12,3 +12,5 @@ obj-y += s390io.o s390mach.o s390dyn.o i
export-objs += ccwcache.o idals.o s390dyn.o s390io.o
include $(TOPDIR)/Rules.make
+
+# the NET subdir is included from drivers/net now
Index: 6-pre2.1/drivers/net/Makefile
--- 6-pre2.1/drivers/net/Makefile Thu, 17 May 2001 10:25:35 +1000 kaos (linux-2.4/l/c/26_Makefile 1.1.1.1.3.3.1.1.1.2 644)
+++ 6-pre2.1(w)/drivers/net/Makefile Wed, 13 Jun 2001 02:03:09 +1000 kaos (linux-2.4/l/c/26_Makefile 1.1.1.1.3.3.1.1.1.2 644)
@@ -214,6 +214,12 @@ subdir-y += ../acorn/net
obj-y += ../acorn/net/acorn-net.o
endif
+ifeq ($(CONFIG_ARCH_S390),y)
+mod-subdirs += ../s390/net
+subdir-y += ../s390/net
+obj-y += ../s390/net/s390-net.o
+endif
+
#
# HIPPI adapters
#
Quoted 2 lines · [email protected] writes:
This is a cure the syntom not the problem, build order shouldn't mess up something this simple.
The refcounting issue you've described is a bug, and so is initializing a network device before net_dev_init() has been invoked. These two things are equally buggy.
Build order does mess up things this simple, look at the comments at the top of drivers/scsi/Makefile if you don't believe me :-)
Later,
David S. Miller
[email protected]
Quoted 3 lines · On Tue, 12 Jun 2001 18:43:41 +0200, [email protected] wrote:
Hi Keith,
This is a cure the syntom not the problem, build order shouldn't mess up something this simple.
I totally agree on one point. Having the automatic initialisers in the same source as the related code is a good idea, it is far better than the old Space.c method. Automatically executing the initialisers in the order they are linked into vmlinux is also a good idea, you must have some automatic order or you are back to the horrors of Space.c. But controlling the link order of the initialisers as a side effect of Makefile compile order sucks big rocks, especially when you have some Makefiles executing other Makefiles which are not their children.
Link order should be independent of Makefile compile order and it should be explicitly specified, instead of occurring as a little known side effect of the convoluted and twisted way that the Makefile tree is processed. Alas Linus likes it this way :(. At least with my 2.5 Makefile rewrite[*] it is more obvious what is going on. I abhore the line order dependencies and controling link order at the level of entire directories when it should be at the level of individual sources.
Quoted 3 lines
I've forwarded your patch to Ulrich & Martin ( the s390 maintainers ) & they may use it
seeing as you & possibly others would prefer a /drivers/net/s390.
DaveM suggested a drivers/net/s390, I recommended against changing the diretory structure right now, wait for 2.5. My patch just changes the compilation order for drivers/s390/net while keeping the same name.
[*] Extract from top level Makefile in my 2.5 rewrite.
# Link order information to build vmlinux.
link_subdirs(arch/$(ARCH)/boot)link_subdirs(init)
link_subdirs($(arch_core_subdirs))
link_subdirs(kernel)link_subdirs(mm)link_subdirs(fs)link_subdirs(ipc)
# FIXME: Built from the DRIVERS definitions in the old Makefile. Some of this
# is just to link intermediate objects into the kernel, some of it is link order # specific but the old Makefile had no documentation. Preserve the old list, # even though most of it is unnecessary. The problem is, we do not know which # bits are necessary because they have link order requirements. Anybody feeling # brave? KAO
link_subdirs(drivers/block)link_subdirs(drivers/char)link_subdirs(drivers/misc)link_subdirs(drivers/net)link_subdirs(drivers/media)
...link_subdirs(drivers/acpi)link_subdirs(drivers/md)
link_subdirs($(arch_drivers_subdirs))
link_subdirs(net)
link_subdirs($(arch_libs))link_subdirs(lib)