public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@infradead.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
	David VomLehn <dvomlehn@cisco.com>,
	<linux-kernel@vger.kernel.org>, <akpm@linux-foundation.org>,
	<linux-usb@vger.kernel.org>, <greg@kroah.com>,
	<linux-scsi@vger.kernel.org>, <netdev@vger.kernel.org>
Subject: Re: [PATCH 1/5] initdev:kernel: Asynchronously-discovered device synchronization, v5
Date: Sun, 3 May 2009 16:21:15 -0700	[thread overview]
Message-ID: <20090503162115.2dff79bd@infradead.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0905021335150.26241-100000@netrider.rowland.org>

On Sat, 2 May 2009 13:55:45 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:

> On Sat, 2 May 2009, James Bottomley wrote:
> 
> > OK, so in your scheme, I get why console devices: they need to be
> > present early before we start dumping console output otherwise it
> > can get lost.
> > 
> > However, I don't see the need for either network or block.
> > 
> > For network, the only early discovery use is net root (which can be
> > done fully asynchronously)
> 
> Are you referring to the "rootwait" kernel parameter?  Is there a 
> reason why this is a boot-time parameter instead of always being
> set? I mean, under what circumstances would you _not_ want to wait
> until the root device is present?

if you have an initrd ;-)
> 
> Perhaps with some enterprise systems, it is preferred to have the 
> system fail with an explicit error message rather than wait 
> indefinitely...

actually, in an enterprise system, you want to reboot.
The bootloader might boot a different kernel the next time
that is known to work.
(for example, the current kernel might have been booted with the "once"
grub option)
> 
> > What I'm getting at is that I don't see the benefit of this in the
> > light of Arjan's async boot system, which can also tell us when all
> > discovery is complete ... what added benefit am I missing here?
> 
> How does Arjan's async boot system tell use when all discovery is
> complete?  AFAICS, it only tells you when all its async tasks are
> finished.  But device discovery and registration sometimes use other
> asynchronous techniques which Arjan's code is unaware of.
> Examples: the USB khubd thread, the USB mass-storage scanning thread,
> and the SCSI async-scanning thread.

for normal device probing we already have infrastructure though...
wait_for_device_probe, driver_probe_done and friends...
(the scsi scanning thread is being converted to the async
infrastructure btw)

do we need to invent more ?

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

  reply	other threads:[~2009-05-03 23:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-02  2:25 [PATCH 1/5] initdev:kernel: Asynchronously-discovered device synchronization, v5 David VomLehn
2009-05-02 13:31 ` Sergey Vlasov
2009-05-02 14:16   ` Alan Stern
2009-05-05  0:33     ` David VomLehn
2009-05-05  0:31   ` [PATCH 1/5] initdev:kernel: Asynchronously-discovered devicesynchronization, v5 David VomLehn
2009-05-02 14:01 ` [PATCH 1/5] initdev:kernel: Asynchronously-discovered device synchronization, v5 James Bottomley
2009-05-02 17:55   ` Alan Stern
2009-05-03 23:21     ` Arjan van de Ven [this message]
2009-05-04 14:30       ` Alan Stern
2009-05-04 14:45         ` Arjan van de Ven
2009-05-04 15:07           ` Alan Stern
2009-05-05 15:47             ` Ming Lei
2009-05-05 15:53               ` Ming Lei
2009-06-05 18:00                 ` David VomLehn
2009-06-05 17:58               ` David VomLehn
2009-05-05  0:55     ` David VomLehn

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=20090503162115.2dff79bd@infradead.org \
    --to=arjan@infradead.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=dvomlehn@cisco.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /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