On Tue, 2002-12-31 at 01:47, Jeff Garzik wrote:
> There will definitely be cases where people will want to black out
> existing entries too.
> Or would that open up to too much potential vendor abuse?
I'm not sure. At the point this occurs the end user has either directly
chosen to replace a driver, or indirectly installed software they want
which does so. It probably should log that an alternative driver setup
has been configured so the user can figure out wtf is going on when
debugging weirdness.
Its providing the same facilities as rm /lib/modules/... at a finer
granularity - if I want to force e100 not eepro100 for a given card for
example.
> > I think it also means we need to be able to go pci table -> owner ?
>
> I don't really see why. If you wanted to be terribly correct have
> these things as refcounting kobjects or similar... But really, with all
> those other wonderfully unlocked PCI lists in the core, why starting
> doing it The Right Way now? ;-)
PCI list locking is easy to fix.
1. Take a list walking semaphore before scanning internally
2. Refcount up the pci device before calling the device inserted method
Refcount down the pci device before calling the device removed method
3. Add pci_lock/unlock functions, and pci_get/put functions
4. Add pci_device_present(vendor, device). Swap the ab-users of pci_
for this to it
5. Clean up drivers as we go along
Almost all the hotplug horrors are zapped at the point #1 and #2 are
done. Its also easy to assert the lock must be taken in pci_find_* when
debugging to squish the rest
Alan
-- It ain't over until the vax server pings..- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Dec 31 2002 - 22:00:18 EST