[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.0905041100500.3092-100000@iolanthe.rowland.org>
Date: Mon, 4 May 2009 11:07:52 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Arjan van de Ven <arjan@...radead.org>
cc: James Bottomley <James.Bottomley@...senPartnership.com>,
David VomLehn <dvomlehn@...co.com>,
<linux-kernel@...r.kernel.org>, <akpm@...ux-foundation.org>,
<linux-usb@...r.kernel.org>, <greg@...ah.com>,
<linux-scsi@...r.kernel.org>, <netdev@...r.kernel.org>
Subject: Re: [PATCH 1/5] initdev:kernel: Asynchronously-discovered device
synchronization, v5
On Mon, 4 May 2009, Arjan van de Ven wrote:
> > > 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 ?
> >
> > I suppose the usb-storage scanning thread could also be converted to
> > the async infrastructure, although I haven't heard of anybody working
> > on it.
> >
> > But the USB hub driver's thread (khubd) cannot be converted. It is
> > central to the discovery of USB-based block devices. How would you
> > handle that?
>
> take a ref in the driver_probe_done() sense, and release it when you
> know you're done probing....
>
> at that point all existing infrastructure will just work.
Isn't there still something missing? The wait_for_device_probe()
routine would wait until all attached devices had been probed. But why
should prepare_namespace() have to wait that long? Wouldn't it be
better to wait only until the root device has been registered?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists