[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090708145625.GA20690@suse.de>
Date: Wed, 8 Jul 2009 07:56:25 -0700
From: Greg KH <gregkh@...e.de>
To: Peter Jones <pjones@...hat.com>
Cc: Dave Airlie <airlied@...il.com>,
Jeff Chua <jeff.chua.linux@...il.com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Scott James Remnant <scott@...onical.com>,
Kay Sievers <kay.sievers@...y.org>,
Dave Jones <davej@...hat.com>
Subject: Re: can we move USB_DEVICEFS to non-embedded?
On Wed, Jul 08, 2009 at 10:12:08AM -0400, Peter Jones wrote:
> Greg KH wrote:
> > On Wed, Jul 08, 2009 at 09:55:04AM -0400, Peter Jones wrote:
> >> On 07/08/2009 09:52 AM, Peter Jones wrote:
> >>> On 07/08/2009 06:54 AM, Dave Airlie wrote:
> >>>
> >>>> I'm not quite sure if something in the F11 initrd needs usbfs for
> >>>> something (cc'ed Peter)
> >>> Not a thing.
> >> Actually, I take it back. We do mount usbfs, and we examine
> >> /proc/bus/usb/devices as a heuristic to try and determine if
> >> all the devices have been enumerated.
> >
> > How can you ever know if all devices are enumerated as you don't know
> > how many devices will be showing up?
>
> You don't, that's why I said it's a heuristic. But basically, we have a
> timeout, and if the device list doesn't change in that amount of time, we
> call it done.
>
> It's not the best technique ever, but it does work.
Works for what? Why would you want to delay your boot process like
this?
> >> So that could be related to what you're seeing.
> >
> > That file is now available in /sys/kernel/debug/usb/devices if you
> > really need it.
>
> Oh, okay. I can change it to use that then.
>
> > But I would think that you do not.
>
> Well, we pretty much do until we switch to dracut.
What is dracut and why would it change this?
As no other distro does this kind of waiting, I'm a bit confused as to
the need for it.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists