Paul Gortmaker wrote: > Jeff Garzik wrote: > > drivers/net/ne.c: > > * use probe_irq_on/off instead of autoirq_xxx (autoirq is going away) > > Would be nice to get verification from someone with an older (non-PnP) > card that this doesn't break the irq detection. Is the game plan to > do similar for other drivers before 2.5.x as well? Have you seen the auto_irq.c code? :) I don't see how it could possibly break, but ya never know... Anyway, to answer your question, yes, Linus has ok'd the elimination of auto_irq.c. It's used in maybe ~10 drivers throughout the kernel, but it is linked into every single kernel built. I created a patch that conditionally linked auto_irq.o in your kernel (or as a module), and Linus said to just get rid of it :) > > * request_region first thing in ne_probe1, before any hardware > > interaction takes place. Eliminates any potential resource races. Also > > eliminates a call to check_region. > > Implementation note - For a lot of the drivers it makes sense to keep > around the resource returned by request_region so that we can set the > name after the probe has taken place (ie when we know what the card is.) > I've included a diff for drivers/net/wd.c as an example of what I > thought looks clean. If I know that the death of check_region is also > a pre 2.4.0 goal then I will supply a diff for the other 17 or so 8390 > based drivers... Definitely a goal. IMHO its a bug if the driver touches the hardware at all before properly "locking" the region first, with locking in this case defined as calling request_region. > On a related note, there are a handful of drivers that register ioports > (and IRQ) with the name dev->name (e.g. eth0) as opposed to a more > meaningful model name (e.g. "3c503/16"). And some drivers do one for > ioports, and the other for IRQ!! We should aim for consistency on this, > and IMHO supplying the model name of the hardware is the more > informative of the two (and also in keeping with the rest of the > kernel drivers). For ISA, it's more informative. For PCI, it's less informative because the requested resource appears in /proc/ioports underneath the parent PCI device. However, the only overriding reason to put dev->name into request_region was for hotplug reasons, because it was otherwise impossible to build an association between a hardware bus device and its respective network interface. With my 'Update hotplug' patch recently posted to lkml, that restriction is gone. Assuming that patch is taken, I have no problem with standardizing on model name instead of dev->name. I agree there should be consistency. > Oh, and while I'm asking about opinions on 2.4.0 goals, what about > the replacement of #ifdef MODULE driver init code with module_init(...)? I'm strongly in favor of it, but I have yet to put some time into thinking of a clean way to do it for ISA drivers. If you have an idea, let's hear it. The big problem is the differences between kernel and module init. Modules get their info MODULE_PARM, and have no ordering constraints. Built-in drivers, on the other hand, need to obey the constraints of the ether=xxx cmd line. Further, I prefer that drivers use init_etherdev to allocate both their netdevice and their struct private at the same time. This removes a lot of unused static gunk in existing ISA drivers. I -think- that you can call init_etherdev(NULL,priv_size) and still get things right WRT ether=xxx, but I'm not totally sure. You may have to abandon init_etherdev altogether, allocating the netdevice+priv yourself, and calling ethdev_setup/register_netdev/etc. manually. > > As an aside, for 2.5.x, would it be possible to merge all the common > > ne2000 code (block_input/output, etc.) from the various ne2k drivers? > > As it stands there exists ne.c, ne2.c, ne2k-pci.c, and pcnet_cs.c, all > > of which do pretty much the same thing at their core. [and AFAICS, all > > but pcnet_cs might easily call a common ne2k library] > > Possible - yes. Worthwhile - not so sure. As it is, 8390.o is the > source of much grief in drivers/net/Makefile from what I read recently ;-) > We will worry about 2.5.x later. True, true. :) > --- 2400-t8/linux-g/drivers/net/wd.c~ Wed Jun 28 11:38:32 2000 > +++ 2400-t8/linux-g/drivers/net/wd.c Tue Sep 19 03:29:52 2000 Thanks, applied. -- Jeff Garzik | Dinner is ready when Building 1024 | the smoke alarm goes off. MandrakeSoft | -/usr/games/fortune - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
