> Richard Guenther wrote:
> > Attached is a patch to support initializing a ISAPnP ne2k clone
> > with the ne.c driver. Unfortunately, deactivating the card at
> > module unload seems to be impossible (or at least hard) due to
> > a lack of a private field in struct net_dev. At least it works
> > for me, but probably other ID's have to be added to the isapnp
> > card list.
> Hi, some comments:
> 1) The fact that the PnP probe you added is a clone of the PCI probe routine
> in the driver brings up an issue that should be considered before we go this
> route - an issue that is being discussed re PCI probing now. i.e. we should
> have isapnp.c contain some sort of function for probing a list of device
> IDs rather than going down the same path again and start adding code
> duplication to a bunch of drivers.
Yes, I think so. Sort of a generic device probe library for different
> 2) If PnP is built into a modular driver then the ne.o module all of a
> sudden requires isapnp.o to be loaded - even for users with non-PnP
> NE2000 cards. (You can pretty much guarantee that distribution maintainers
> would ship a ne.o module with PnP support enabled if it was an available
> option). Even with PnP cards the current setup allows you to load the isapnp
> module, activate the card(s) via /proc and then unload - i.e. it doesn't
> require leaving the isapnp module loaded.
Ah, I see. But its the same issue with PCI and CONFIG_PCI? You are not
worried about the size of the isapnp code itself but about the
(perhaps unnecessary) size increase of the ne module?
This is surely true for vendor shipped kernels, but the isapnp code in
the kernel makes sense only for in-kernel drivers which cannot be
initted by the user space tools. In this case one would build a custom
kernel anyways because the vendors ship all drivers as modules.
So I agree basically, but dont really care :) (well, if we get zillions
of different busses and probe code in the future this would change
probably, but at the moment it seems PCI/CardBus and ISAPnP for some
> 3) In your patch, the probe/ID table aren't in #ifdef CONFIG_ISAPNP.
> While this is not strictly required for it to compile thanks to the dummy
> functions in isapnp.h, it makes for a smaller driver module since __initXXX
> doesn't (currently) do anything for modules. (This can cost you an extra
> page if it causes the module to exceed a PAGE_SIZE boundary)
Yes, I tried to avoid having #ifdef CONFIG_ISAPNP all around (which is
why I like the dummy functions present in all core-functionaly code
that can be configured out). For the probe table, it would make sense
(especially as it would grow larger in the future).
> 4) You can handle the issue of deactiviation via keeping a linked list
> of PnP ne2k cards you find - you can swipe the code for this directly
> from ne2k-pci.c
I've done it different in the second patch - I'm using the
ei_local->private field to store the struct pci_dev.
> I think having the PnP probe in the driver is probably a win in terms of
> idiot proofing novice installs but (1) should be sorted first and I'm not
> keen on what (2) implies. Fixing (3) is trivial. Since use of PnP ISA
> ne2k cards isn't reliant on adding the PnP probe (e.g. just disable PnP on
> the card) and since the PnP probe routines are new and currently unused
> in any other driver so we could leave this post 2.4 release. (Otherwise
> we should add it to all the other drivers for ISA PnP devices b4 2.4.0)
well, I did it for me to get rid of the userspace isapnp tools :)
So (1) is surely very high-priority especially as support for ISAPnP
in other drivers will pop up, if someone needs it.
(2) is not an issue, I think (apart from (3), #ifdef'ing the probe table)
- one should add a simple HOWTO to (1) how to do it right.
PS: it seems Alan has put it into 2.3.18ac??, so I cc'ed him on this
-- Richard Guenther <firstname.lastname@example.org> PGP: 2E829319 - 2F 83 FC 93 E9 E4 19 E2 93 7A 32 42 45 37 23 57 WWW: http://www.anatom.uni-tuebingen.de/~richi/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com Please read the FAQ at http://www.tux.org/lkml/