commit cc71329b3b89b4a5be849b617f2c4f151f0b9213 moved USB_DEVICEFS to
be embedded and marked it as depreciated. Can this be reverted? This
breaks vmware and those systems not using udev.
Here's a small patch to move it as non-embedded.
Thanks,
Jeff.
On Tue, 2009-06-23 at 13:11 +0800, Jeff Chua wrote:
> commit cc71329b3b89b4a5be849b617f2c4f151f0b9213 moved USB_DEVICEFS to
> be embedded and marked it as depreciated. Can this be reverted? This
> breaks vmware and those systems not using udev.
>
vmware should have been updated to use /dev/bus/usb a long time ago.
I believe that the old devices file is available under debugfs now, if
you need it.
Scott
--
Scott James Remnant
[email protected]
On Tue, Jun 23, 2009 at 01:11:51PM +0800, Jeff Chua wrote:
> commit cc71329b3b89b4a5be849b617f2c4f151f0b9213 moved USB_DEVICEFS to
> be embedded and marked it as depreciated. Can this be reverted? This
> breaks vmware and those systems not using udev.
vmware now works properly with this fix, and has for over a year or so.
What distro does not use udev or mdev or something like it already and
also does not use an updated libusb?
We need some specifics here please.
thanks,
greg k-h
On Tue, Jun 23, 2009 at 10:42 PM, Greg KH<[email protected]> wrote:
> On Tue, Jun 23, 2009 at 01:11:51PM +0800, Jeff Chua wrote:
>> commit cc71329b3b89b4a5be849b617f2c4f151f0b9213 moved USB_DEVICEFS to
>> be embedded and marked it as depreciated. Can this be reverted? This
>> breaks vmware and those systems not using udev.
> vmware now works properly with this fix, and has for over a year or so.
vmware is working, but can't detect USB devices.
> What distro does not use udev or mdev or something like it already and
> also does not use an updated libusb?
> We need some specifics here please.
I'm not using it and have been fine without it all these while, so
don't see any gain moving to udev or perhaps it's time to consider ...
Thanks,
Jeff.
On Tue, Jun 23, 2009 at 11:29:50PM +0800, Jeff Chua wrote:
> On Tue, Jun 23, 2009 at 10:42 PM, Greg KH<[email protected]> wrote:
> > On Tue, Jun 23, 2009 at 01:11:51PM +0800, Jeff Chua wrote:
> >> commit cc71329b3b89b4a5be849b617f2c4f151f0b9213 moved USB_DEVICEFS to
> >> be embedded and marked it as depreciated. Can this be reverted? This
> >> breaks vmware and those systems not using udev.
>
> > vmware now works properly with this fix, and has for over a year or so.
>
> vmware is working, but can't detect USB devices.
Odd, what version of vmware are you using?
> > What distro does not use udev or mdev or something like it already and
> > also does not use an updated libusb?
> > We need some specifics here please.
>
> I'm not using it and have been fine without it all these while, so
> don't see any gain moving to udev or perhaps it's time to consider ...
If you are running your own custom distro/install, then you should be
able to select CONFIG_EMBEDDED and then USB_DEVICEFS just fine on your
own. But note, that you don't sound like the "normal" user at all :)
thanks,
greg k-h
On Wed, Jun 24, 2009 at 1:39 AM, Greg KH<[email protected]> wrote:
> On Tue, Jun 23, 2009 at 11:29:50PM +0800, Jeff Chua wrote:
>> On Tue, Jun 23, 2009 at 10:42 PM, Greg KH<[email protected]> wrote:
>> > On Tue, Jun 23, 2009 at 01:11:51PM +0800, Jeff Chua wrote:
>> >> commit cc71329b3b89b4a5be849b617f2c4f151f0b9213 moved USB_DEVICEFS to
>> >> be embedded and marked it as depreciated. Can this be reverted? This
>> >> breaks vmware and those systems not using udev.
>>
>> > vmware now works properly with this fix, and has for over a year or so.
>>
>> vmware is working, but can't detect USB devices.
>
> Odd, what version of vmware are you using?
>
>> > What distro does not use udev or mdev or something like it already and
>> > also does not use an updated libusb?
>> > We need some specifics here please.
>>
>> I'm not using it and have been fine without it all these while, so
>> don't see any gain moving to udev or perhaps it's time to consider ...
>
> If you are running your own custom distro/install, then you should be
> able to select CONFIG_EMBEDDED and then USB_DEVICEFS just fine on your
> own. ?But note, that you don't sound like the "normal" user at all :)
>
Okay can we revert this for a better reason? it seems to have unhidden a race
condition on booting some of my machines. I've booted some other machines
with the same USB disk and the same kernel fine. The two machines it so far
has turned up issues on are an AMD 1Ghz Athlon with SIS chipset, the other is
an Intel Celeron CPU with a AMD rc410 chipset.
If I take a stock F11 distro, and build 2.6.31-rc2 on a USB HDD root,
I can't boot
I'm not quite sure if something in the F11 initrd needs usbfs for
something (cc'ed Peter)
The same hang happens if I boot a 2.6.30 kernel with an F11 initrd and
with usbfs turned off.
Also for reference all rawhide kernels fail to boot on the same F11 system.
I haven't tried using a rawhide initrd due to rawhide being a bit
unusable at the moment.
Dave.
On Wed, Jul 8, 2009 at 12:54, Dave Airlie<[email protected]> wrote:
> Okay can we revert this for a better reason? it seems to have unhidden a race
> condition on booting some of my machines. I've booted some other machines
> with the same USB disk and the same kernel fine.
Are you sure? USBFS is for userspace USB drivers, booting from
usb-storage devices should be fully handled by the kernel.
Thanks,
Kay
On Wed, Jul 8, 2009 at 9:03 PM, Kay Sievers<[email protected]> wrote:
> On Wed, Jul 8, 2009 at 12:54, Dave Airlie<[email protected]> wrote:
>
>> Okay can we revert this for a better reason? it seems to have unhidden a race
>> condition on booting some of my machines. I've booted some other machines
>> with the same USB disk and the same kernel fine.
>
> Are you sure? USBFS is for userspace USB drivers, booting from
> usb-storage devices should be fully handled by the kernel.
>
Yes, changing just this option means the difference between a bootable
and stuck in initrd system. maybe Peter knows if our initrd does something
otherwise I suspect we have a race that usbfs was hiding.
Dave.
On Wed, 2009-07-08 at 21:20 +1000, Dave Airlie wrote:
> On Wed, Jul 8, 2009 at 9:03 PM, Kay Sievers<[email protected]> wrote:
> > On Wed, Jul 8, 2009 at 12:54, Dave Airlie<[email protected]> wrote:
> >
> >> Okay can we revert this for a better reason? it seems to have unhidden a race
> >> condition on booting some of my machines. I've booted some other machines
> >> with the same USB disk and the same kernel fine.
> >
> > Are you sure? USBFS is for userspace USB drivers, booting from
> > usb-storage devices should be fully handled by the kernel.
> >
>
> Yes, changing just this option means the difference between a bootable
> and stuck in initrd system. maybe Peter knows if our initrd does something
> otherwise I suspect we have a race that usbfs was hiding.
>
I assume you're not using libusual or anything like that? We had a race
caused by libusual calling modprobe before we'd generated modules.dep
Scott
--
Scott James Remnant
[email protected]
On Wed, Jul 08, 2009 at 09:20:04PM +1000, Dave Airlie wrote:
> On Wed, Jul 8, 2009 at 9:03 PM, Kay Sievers<[email protected]> wrote:
> > On Wed, Jul 8, 2009 at 12:54, Dave Airlie<[email protected]> wrote:
> >
> >> Okay can we revert this for a better reason? it seems to have unhidden a race
> >> condition on booting some of my machines. I've booted some other machines
> >> with the same USB disk and the same kernel fine.
> >
> > Are you sure? USBFS is for userspace USB drivers, booting from
> > usb-storage devices should be fully handled by the kernel.
> >
>
> Yes, changing just this option means the difference between a bootable
> and stuck in initrd system. maybe Peter knows if our initrd does something
> otherwise I suspect we have a race that usbfs was hiding.
Like Kay stated, this sounds very strange, I'd like to find out the root
cause of this before reverting the config option. Nothing at startup
should be using/needing usbfs that I can think of.
thanks,
greg k-h
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.
--
Peter
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.
So that could be related to what you're seeing.
--
Peter
I number the Linux folks among my personal heroes.
-- Donald Knuth
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?
> 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.
But I would think that you do not.
thanks,
greg k-h
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.
>> 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.
--
Peter
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
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 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.
> 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.
--
Peter
Greg KH ([email protected]) said:
> > 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.
How is a deprecated-but-stable filesystem ABI better than a guaranteed-to-
not-be-stable debugfs ABI?
Bill
On Wed, Jul 08, 2009 at 11:12:58AM -0400, Bill Nottingham wrote:
> Greg KH ([email protected]) said:
> > > 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.
>
> How is a deprecated-but-stable filesystem ABI better than a guaranteed-to-
> not-be-stable debugfs ABI?
The filesystem is still there, it is just accessed differently (through
/dev nodes) and has been for many years now.
We depreciated the filesystem access because it causes lots of confusion
for users.
The devices file has been full of races and can't be fixed in a sane
way, which is why we moved it to debugfs. I am very surprised that your
boot process relies on it.
thanks,
greg k-h
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?
thanks,
greg k-h
On Thu, Jul 9, 2009 at 1:47 AM, Greg KH<[email protected]> 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.
On Thu, Jul 9, 2009 at 5:23 AM, Dave Airlie<[email protected]> wrote:
> So I don't think CONFIG_EMBEDDED is correct at least at this point.
Without CONFIG_EMBEDDED ...
CONFIG_NAMESPACES=y
With CONFIG_EMBEDDED=y ...
# CONFIG_NAMESPACES is not set
CONFIG_VMSPLIT_3G=y
I can't find a place to change these using menuconfig when EMBEDDED is selected.
I agree that CONFIG_EMBEDDED is not the right place to hide this
becuase it changed the behavior of more than just usbfs.
Thanks,
Jeff
On Thu, Jul 09, 2009 at 07:23:23AM +1000, Dave Airlie wrote:
> On Thu, Jul 9, 2009 at 1:47 AM, Greg KH<[email protected]> 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
Jeff Chua wrote:
> On Thu, Jul 9, 2009 at 5:23 AM, Dave Airlie<[email protected]> wrote:
>
>> So I don't think CONFIG_EMBEDDED is correct at least at this point.
>
> Without CONFIG_EMBEDDED ...
> CONFIG_NAMESPACES=y
Under General Setup, Namespaces support
> With CONFIG_EMBEDDED=y ...
> # CONFIG_NAMESPACES is not set
> CONFIG_VMSPLIT_3G=y
>
> I can't find a place to change these using menuconfig when EMBEDDED is selected.
Under Processor type and features, Memory split
> I agree that CONFIG_EMBEDDED is not the right place to hide this
> becuase it changed the behavior of more than just usbfs.
~Randy
On Thu, Jul 9, 2009 at 9:59 AM, Randy Dunlap<[email protected]> wrote:
>> Without CONFIG_EMBEDDED ...
>> ? CONFIG_NAMESPACES=y
> Under General Setup, Namespaces support
You're good. Thanks.
>> With CONFIG_EMBEDDED=y ...
>> ? # CONFIG_NAMESPACES is not set
>> ? CONFIG_VMSPLIT_3G=y
> Under Processor type and features, Memory split
This is one I'm having trouble with. When CONFIG_EMBEDED is not set, I
can't find any "VMSPLIT" in .config, but when CONFIG_EMBEDDED is set,
I'll have to choose the VMSPLIT option. Should I select VMSPLIT_3G?
Here's what it says ...
| Prompt: Memory split
| Defined at arch/x86/Kconfig:1062
| Depends on: EXPERIMENTAL && X86_32 && EMBEDDED
| Location:
| -> Processor type and features
| Selected by: EXPERIMENTAL && X86_32 && EMBEDDED && m
Thanks,
Jeff.
Jeff Chua wrote:
> On Thu, Jul 9, 2009 at 9:59 AM, Randy Dunlap<[email protected]> wrote:
>>> Without CONFIG_EMBEDDED ...
>>> CONFIG_NAMESPACES=y
>> Under General Setup, Namespaces support
>
> You're good. Thanks.
>
>>> With CONFIG_EMBEDDED=y ...
>>> # CONFIG_NAMESPACES is not set
>>> CONFIG_VMSPLIT_3G=y
>> Under Processor type and features, Memory split
>
> This is one I'm having trouble with. When CONFIG_EMBEDED is not set, I
> can't find any "VMSPLIT" in .config, but when CONFIG_EMBEDDED is set,
> I'll have to choose the VMSPLIT option. Should I select VMSPLIT_3G?
Probably so, since that's the default.
> Here's what it says ...
>
> | Prompt: Memory split
> | Defined at arch/x86/Kconfig:1062
> | Depends on: EXPERIMENTAL && X86_32 && EMBEDDED
> | Location:
> | -> Processor type and features
> | Selected by: EXPERIMENTAL && X86_32 && EMBEDDED && m
arch/x86/Kconfig says:
choice
depends on EXPERIMENTAL
prompt "Memory split" if EMBEDDED
default VMSPLIT_3G
depends on X86_32
---help---
Select the desired split between kernel and user memory.
If the address range available to the kernel is less than the
physical memory installed, the remaining memory will be available
as "high memory". Accessing high memory is a little more costly
than low memory, as it needs to be mapped into the kernel first.
Note that increasing the kernel address space limits the range
available to user programs, making the address space there
tighter. Selecting anything other than the default 3G/1G split
will also likely make your kernel incompatible with binary-only
kernel modules.
If you are not absolutely sure what you are doing, leave this
option alone!
~Randy
On Thu, Jul 9, 2009 at 11:01 AM, Randy Dunlap<[email protected]> wrote:
> arch/x86/Kconfig says:
>
> choice
> ? ? ? ?depends on EXPERIMENTAL
> ? ? ? ?prompt "Memory split" if EMBEDDED
> ? ? ? ?default VMSPLIT_3G
> ? ? ? ?depends on X86_32
> ? ? ? ?---help---
> ? ? ? ? ?Select the desired split between kernel and user memory.
>
> ? ? ? ? ?If the address range available to the kernel is less than the
> ? ? ? ? ?physical memory installed, the remaining memory will be available
> ? ? ? ? ?as "high memory". Accessing high memory is a little more costly
> ? ? ? ? ?than low memory, as it needs to be mapped into the kernel first.
> ? ? ? ? ?Note that increasing the kernel address space limits the range
> ? ? ? ? ?available to user programs, making the address space there
> ? ? ? ? ?tighter. ?Selecting anything other than the default 3G/1G split
> ? ? ? ? ?will also likely make your kernel incompatible with binary-only
> ? ? ? ? ?kernel modules.
Got it. Thanks for the pointer.
Jeff.