lkml.org 
[lkml]   [2002]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Removal of pci_find_* in 2.5
On Sat, Jul 13, 2002 at 12:41:56AM -0400, Jeff Garzik wrote:
> Matt_Domsch@Dell.com wrote:
> >In both these cases, the pci_find_device() functions use an explict
> >ordering
> >to make it far more likely we can still boot the system after adding new
> >hardware. Unless/until there's a method for telling the kernel/modules
> >that
> >a particular device is the boot device (ala BIOS EDD 3.0 if vendors were to
> >get around to implementing such) explict ordering in the drivers is the
> >only
> >way we can build complex storage solutions and boot reliably.
>
>
> IMO what devices are boot devices is a policy decision. Depending on
> pci_find_device() use in a driver's kernel code, or kernel link
> 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.

Exactly.

In the way we are moving naming policy out to userspace, you will be
able to specify exactly which disk, on which pci bus that you want to
boot from (remember initramfs will let us run userspace programs before
the boot disk is touched by the kernel.)

Yes, it still involves some handwaving at this moment in time, but it
will happen, and I do know about this requirement :)

thanks,

greg k-h
-
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.071 / U:2.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site