Messages in this thread | | | Date | Wed, 8 Jul 2009 18:33:12 -0700 | From | Greg KH <> | Subject | Re: can we move USB_DEVICEFS to non-embedded? |
| |
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@suse.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.
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |