Re: can we move USB_DEVICEFS to non-embedded?

[Greg KH]

On Thu, Jul 09, 2009 at 07:23:23AM +1000, Dave Airlie wrote:
> On Thu, Jul 9, 2009 at 1:47 AM, Greg KH<gregkh@xxxxxxx> 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.

Agreed.

Can I get an acknowledgment that the version in RawHide is fixed up to
work properly with this, so that I have a baseline on when I can put
this option back in the embedded section?

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

That's good to remember.  And to also note that you are relying on an
unreliable thing.

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

"Nobody sane" that is :)

Oh, Gentoo and Mandrake and Debian and Moblin and montavista and
windriver also don't use this, so you all are in the miniority here.

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

Agreed, I'll queue up a patch to revert it.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/