Message-ID: <21d7e9970907081423v6d3830eey227f3d54b10382a6@mail.gmail.com>
Date:	Thu, 9 Jul 2009 07:23:23 +1000
From:	Dave Airlie <airlied@...il.com>
To:	Greg KH <gregkh@...e.de>
Cc:	Peter Jones <pjones@...hat.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 Thu, Jul 9, 2009 at 1:47 AM, Greg KH<gregkh@...e.de> wrote:
> On Wed, Jul 08, 2009 at 11:05:38AM -0400, Peter Jones wrote:
>> Greg KH wrote:
>> > 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?
>>
>> Because otherwise when we actually get to mounting the root filesystem,
>> the device *isn't yet present*.
>
> So this is your solution to the "root fs on usb device" problem?  That's
> odd that you chose this manner, as it still is not "correct" as has been
> seen on different bug reports over the years on lkml.
>
>> >>>> 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?
>>
>> It's the replacement for mkinitrd, and it's using hotplug events for
>> this stuff instead.
>
> Ah, good, yes, that is the correct solution.
>
>> > As no other distro does this kind of waiting, I'm a bit confused as to
>> > the need for it.
>>
>> Good to know you pay attention to what's going on in the Linux world.
>
> Oh, I do, I just don't think you are noticing us making distros now
> without any initrd, or very stripped down ones, in order to achieve fast
> boot times.  Look at the moblin images from Intel, or the goblin images
> from openSUSE to see that happening today.
>
> So, back to the original problem here, is usbfs a requirement for Fedora
> machines to boot properly?  Or has that now been fixed in your repo?
>

We can't travel back in time even if we fix it in the repo, we have F10 and
F11 systems out there that people expect to use.

I would actually expect this initrd using usbfs predates all the hotplug stuff
we do it in RHEL5 also,its comes from a time when we had to make stuff
work with what was available at the time, I'd guess the wheel has been
reinvented 2-3 times in that era, however usbfs has always worked for us.

so when you guys said nobody uses this, you meant SuSE and Ubuntu
don't use this, not nobody.

So I don't think CONFIG_EMBEDDED is correct at least at this point.

Dave.
--
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