lkml.org 
[lkml]   [2002]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Removal of pci_find_* in 2.5
From
Date
On Sat, 2002-07-13 at 05:41, Jeff Garzik wrote:
> ordering, is simply hard-coding something that should really be in
> userspace. Depending on pci_find_device logic / link order to
> still-boot-the-system after adding new hardware sounds like an
> incredibly fragile hope, not a reliable system users can trust.

For hot plugging obvious. At system boot time however the ordering and
seeing the ordering is rather important because in many cases the
ordering is what tells you about things like IDE controller pairing. It
tells you what order to assign many scsi devices because the ordering is
defined by their BIOS ROM.

One way to handle this generically would be to use pci_register_device,
but in the register function for such wacky devices during boot up we
merely keep track of what we have to look into.

That requires a way for drivers to register an init function that will
be called after the boot time PCI device registration is done. At that
point its as easy as

Register
Collect list of devices

[Kernel does pci enumerations]

Sort list in BIOS specific ordering
Feed list to registration code
Flip registration function pointer to be the immediate register
handler

[Watch all the glue vanish into __init oblivion]

Which seems preferable to keeping the old API around for registrations,
although its still used for probing for things (which has locking
concerns). Refcounting pci_ might sort those out

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

\
 
 \ /
  Last update: 2005-03-22 13:27    [W:0.428 / U:1.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site