> > 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> busses.

Yes I know about this. Moving it is on the tag list as is moving pci-scanout of drivers/net

> 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> legacy support)

Boot time ISAPnP init isnt too big. Fixing the drivers is also fairlyeasy because we can do this

static struct blah...{ }; isapnp_scan(&blah)

and if isapnp_scan ifdefs to nothing when ISAPNP is disabled then the struct shouldnt be compiled into the code. If it is then someoneneeds to take a large stick to gcc..

> 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.

And you can now nfsroot off an isapnp card 8)

-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.rutgers.eduPlease read the FAQ at http://www.tux.org/lkml/