public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Matt_Domsch@Dell.com, alan@lxorguk.ukuu.org.uk,
	linux-kernel@vger.kernel.org
Cc: Jeff Garzik <jgarzik@mandrakesoft.com>
Subject: Re: Removal of pci_find_* in 2.5
Date: Fri, 12 Jul 2002 22:09:52 -0700	[thread overview]
Message-ID: <20020713050952.GA13030@kroah.com> (raw)
In-Reply-To: <3D2FAF94.7070100@mandrakesoft.com>

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

  reply	other threads:[~2002-07-13  5:07 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-13  4:04 Removal of pci_find_* in 2.5 Matt_Domsch
2002-07-13  4:41 ` Jeff Garzik
2002-07-13  5:09   ` Greg KH [this message]
2002-07-13 14:35   ` Alan Cox
2002-07-13 15:37     ` Jeff Garzik
2002-07-13 17:06       ` Alan Cox
2002-07-13 19:28         ` Jeff Garzik
2002-07-13 19:33           ` Jeff Garzik
  -- strict thread matches above, loose matches on Subject: below --
2002-07-16 19:23 Matt_Domsch
2002-07-13 13:13 Matt_Domsch
2002-07-13  0:36 Greg KH
2002-07-13  2:23 ` Alan Cox
2002-07-13  1:12   ` David S. Miller
2002-07-13 14:46     ` Alan Cox
2002-07-13 20:52       ` David S. Miller
2002-07-13 13:45         ` Benjamin Herrenschmidt
2002-07-15  5:25           ` David S. Miller
2002-07-16  0:26             ` Greg KH
2002-07-14 20:07 ` Eric W. Biederman
2002-07-16  0:25   ` Greg KH
2002-07-16 10:56     ` Eric W. Biederman
2002-07-16 17:33       ` Patrick Mochel
2002-07-17 12:41         ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020713050952.GA13030@kroah.com \
    --to=greg@kroah.com \
    --cc=Matt_Domsch@Dell.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=jgarzik@mandrakesoft.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox