Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 480312 - OpenRC: /etc/init.d/procfs has code for legacy kernels that is obsolete
Summary: OpenRC: /etc/init.d/procfs has code for legacy kernels that is obsolete
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: OpenRC (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: OpenRC Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: openrc-0.14
  Show dependency tree
 
Reported: 2013-08-09 04:14 UTC by Patrick Lauer
Modified: 2015-04-20 16:43 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Lauer gentoo-dev 2013-08-09 04:14:39 UTC
Parts of this block can be simplified - the whole check is useless on all supported kernels.

        # Check what USB fs the kernel support.  Currently
        # 2.5+ kernels, and later 2.4 kernels have 'usbfs',
        # while older kernels have 'usbdevfs'.
        if [ -d /proc/bus/usb -a ! -e /proc/bus/usb/devices ]; then
                local usbfs=$(grep -Fow usbfs /proc/filesystems ||
                        grep -Fow usbdevfs /proc/filesystems)
                if [ -n "$usbfs" ]; then
                        ebegin "Mounting USB device filesystem [$usbfs]"
                        local usbgid="$(getent group usb | \
                                sed -e 's/.*:.*:\(.*\):.*/\1/')"
                        mount -t $usbfs \
                                -o ${usbgid:+devmode=0664,devgid=$usbgid,}noexec,nosuid \
                                usbfs /proc/bus/usb
                        eend $?
                fi
        fi
Comment 1 William Hubbs gentoo-dev 2013-09-01 16:37:42 UTC
(In reply to Patrick Lauer from comment #0)
> Parts of this block can be simplified - the whole check is useless on all
> supported kernels.

It sounds like you are saying I can remove the whole block -- correct?
Comment 2 Duncan 2013-10-25 11:29:25 UTC
(In reply to William Hubbs from comment #1)
> (In reply to Patrick Lauer from comment #0)
> > Parts of this block can be simplified - the whole check is useless on all
> > supported kernels.
> 
> It sounds like you are saying I can remove the whole block -- correct?

A quick google says support for usbfs mounting at /proc/bus/usb was dropped from 2.6.32 (there's /dev/bus/usb and /sys/bus/usb now).  All gentoo-sources versions are 3.x now, so from that it would be safe to drop that whole test.

Tho xbox-sources are stuck back at 2.6.16 and openvz-sources at 2.6.32.  Does gentoo/openrc continue to support those AND do they support USB?  If so...

Everything else appears to have a 3.x kernel available at least, tho I didn't check stable/~ status.
Comment 3 Duncan 2013-10-25 11:49:33 UTC
(In reply to Duncan from comment #2)

> A quick google says support for usbfs mounting at /proc/bus/usb was dropped
> from 2.6.32

/Too/ quick a google, I think!  Turns out that might have been when it was deprecated, or when some distro removed it, but the deprecated usbfs wasn't actually removed from the kernel until 3.5.

And I expect we have some dragging archs still on 3.4 or earlier for stable, tho they might not support usb.  Regardless, given the 3.5 usbfs removal status it's probably a bit early to remove the test for it entirely.  =:^(  Maybe in another year or so...
Comment 4 KK 2014-03-18 14:27:55 UTC
There is another twist to this script: The first part in the start() function reading:

# Make sure we insert usbcore if it's a module
if [ -f /proc/modules -a ! -d /sys/module/usbcore -a ! -d /proc/bus/usb ]; then
       modprobe -q usbcore
fi

seems to be wrong because it unconditionally loads the usbcore module (and in turn usbcommon) even if the system does _not_ contain any USB hardware. I have experienced this on a XEN PV guest without any USB controller being passed through. usbcore and usbcommon were nevertheless loaded.

I am not sure how to properly handle this - I have currently just commented out the 'modprobe -q' usbcore and replaced it with a ':' but that does not seem to be a proper fix. If loading of usbcore is actually required for whatever reason at that point in time when procfs is being executed, it should only be loaded in case there is USB hardware available or it should be unloaded afterwards if no hardware is present (provided a check if hardware is present depends on usbcore being loaded).

Furthermore, for an identical XEN guest _with_ USB hardware passed through usbcore and usbcommon _were_ actually loaded even when the modprobe -q usbcore was commented out in /etc/init.d/procfs. It seems usbcore gets loaded anyway and independent of /etc/init.d/profcs if and when required. So this really poses the question why does procfs actually think it needs to load usbcore?

My suspicion is that this might only be for the 'useless check' [(c) Patrick] further down and it could as well be dropped all together.
Comment 5 nobody 2015-04-10 23:39:43 UTC
I agree loading usbcore module makes no sense, if people have usb and need it at boot, they will be force to use it inside kernel and not as module.
If people need it later and build it as module, dev manager or the user itself (by hand or thru module.autoload) could ask to load it.
openrc shouldn't just load a module for the only reason the module was built.

I disagree removing usbfs check: not everyone use a kernel without it, not everyone use openrc with gentoo (something even as a gentoo host project, you should never forget).
And the second point is that it doesn't do any harm, as it check if the usbfs exists, the check itself is sane.
I have no use myself of usbfs, but you don't know if someone is not using it.

The supported kernel list in gentoo doesn't define the support kernel list in openrc, as openrc itself is gentoo project, but not limited to gentoo usage ; so it would be a mistake to limit openrc to gentoo supported kernel list.
Comment 6 Joshua Kinard gentoo-dev 2015-04-11 05:15:25 UTC
I assume the block has no purpose or function on Gentoo/FreeBSD as well?
Comment 7 William Hubbs gentoo-dev 2015-04-11 18:56:26 UTC
(In reply to Joshua Kinard from comment #6)
> I assume the block has no purpose or function on Gentoo/FreeBSD as well?

Correct, the procfs service doesn't get installed on *BSD, so that is not relevant.

(In reply to nobody from comment #5)

*snip*

> I disagree removing usbfs check: not everyone use a kernel without it, not
> everyone use openrc with gentoo (something even as a gentoo host project,
> you should never forget).
> And the second point is that it doesn't do any harm, as it check if the
> usbfs exists, the check itself is sane.
> I have no use myself of usbfs, but you don't know if someone is not using it.

I'm not thinking about the supported kernel  list in Gentoo, but the list on https://www.kernel.org. Also, I'm thinking about the device managers I know about (udev and eudev). as far as I know, they all use information in /sys/bus/usb these days.

If there is something I'm missing, I'm all ears. :-)
Comment 8 SpanKY gentoo-dev 2015-04-16 20:59:56 UTC
while Gentoo has specific kernel versions that are supported, that doesn't mean other packages cannot support other versions.  we often keep packages in the tree specifically to work with older versions.  that said, usbfs wasn't entirely dropped until linux-3.5 and we def support versions older than that.

we do not require udev though.

we could split usbfs out into a sep func and put it behind a config knob (disabled by default).  and move the usbcore logic into that.  it's not like the code really ever changes, so the overhead here is minimal.

(In reply to KK from comment #4)

if you don't want modules loaded/probed, then don't enable them.  that's not really our problem.  usbfs is provided by usbcore, so it needs to be loaded before the fs can be detected/mounted.
Comment 9 KK 2015-04-16 21:21:17 UTC
(In reply to SpanKY from comment #8)
> if you don't want modules loaded/probed, then don't enable them.  that's not
> really our problem.  usbfs is provided by usbcore, so it needs to be loaded
> before the fs can be detected/mounted.
In my view that's not the proper approach and, unfortunately, you are not making any distinction between a mere probing (which is o.k.) and an unconditional loading even if no hardware requiring that module is present. In case there's no USB hardware present the init system should not just blindly load (and keep loaded) USB modules just because they happen to be available as modules.

A modular kernel, by design, is modular and should only load what is required (i.e. to support _available_ hardware) regardless of the number of modules built.

In my use case I am using a kernel that is shared across a number of virtual machines on XEN and a only a small subset of these VMs requires USB (provided via PCI passthrough); the majority of my VMs do not require USB and thus do not get any USB devices passed from the host.

If you say that it is required for whatever reason then a proper approach IMHO would be to unload the module afterwards if it turned out that the loading, in fact, was not necessary.

Furthermore even if I comment out the loading of the module, USB support for those systems that have USB hardware passed through is still available once the system is up. So there must be a way to check for hardware availability before unconditionally loading driver (and thus wasting memory).

Thanks KK
Comment 10 SpanKY gentoo-dev 2015-04-16 21:36:12 UTC
(In reply to KK from comment #9)

it isn't loading random usb modules, it's loading the core which is fairly small.  your use case is uncommon enough to not waste time on.
Comment 11 William Hubbs gentoo-dev 2015-04-17 16:01:32 UTC
(In reply to SpanKY from comment #10)
> (In reply to KK from comment #9)
> 
> it isn't loading random usb modules, it's loading the core which is fairly
> small.  your use case is uncommon enough to not waste time on.

@vapier:
Will usbcore be loaded by the device manager (e.g. udev/eudev) If it is needed? If that answer is yes, I don't really see a need for OpenRC to modprobe usbcore on its own.
Comment 12 William Hubbs gentoo-dev 2015-04-17 16:15:49 UTC
(In reply to KK from comment #4)
> There is another twist to this script: The first part in the start()
> function reading:
> 
> # Make sure we insert usbcore if it's a module
> if [ -f /proc/modules -a ! -d /sys/module/usbcore -a ! -d /proc/bus/usb ];
> then
>        modprobe -q usbcore
> fi

This test appears to be wrong  because /proc/bus/usb does not exist for modern kernels. I don't know when it went away, but I'm running 4.0.0 here and that directory does not exist even when /sys/module/usbcore does.

> seems to be wrong because it unconditionally loads the usbcore module (and
> in turn usbcommon) even if the system does _not_ contain any USB hardware. I
> have experienced this on a XEN PV guest without any USB controller being
> passed through. usbcore and usbcommon were nevertheless loaded.
> 
> I am not sure how to properly handle this - I have currently just commented
> out the 'modprobe -q' usbcore and replaced it with a ':' but that does not
> seem to be a proper fix. If loading of usbcore is actually required for
> whatever reason at that point in time when procfs is being executed, it
> should only be loaded in case there is USB hardware available or it should
> be unloaded afterwards if no hardware is present (provided a check if
> hardware is present depends on usbcore being loaded).
> 
> Furthermore, for an identical XEN guest _with_ USB hardware passed through
> usbcore and usbcommon _were_ actually loaded even when the modprobe -q
> usbcore was commented out in /etc/init.d/procfs. It seems usbcore gets
> loaded anyway and independent of /etc/init.d/profcs if and when required. So
> this really poses the question why does procfs actually think it needs to
> load usbcore?
> 
> My suspicion is that this might only be for the 'useless check' [(c)
> Patrick] further down and it could as well be dropped all together.

I'm thinking this if block should be removed from procfs.
Comment 13 nobody 2015-04-18 10:03:28 UTC
(In reply to William Hubbs from comment #12)
> > # Make sure we insert usbcore if it's a module
> > if [ -f /proc/modules -a ! -d /sys/module/usbcore -a ! -d /proc/bus/usb ];
> > then
> >        modprobe -q usbcore
> > fi
> 
> This test appears to be wrong  because /proc/bus/usb does not exist for
> modern kernels. I don't know when it went away, but I'm running 4.0.0 here
> and that directory does not exist even when /sys/module/usbcore does.
> 
You are hard to follow, really.
This test is wrong on modern kernels but good for older ones supporting usbfs
I'm fine you remove the check to not load usbcore module at all and leave that to user/udev(& co), fine if you remove it to unconditionaly load usbcore...

You should first decide if you support older kernel and their scheme to handle usb, as i already said, i'm not for removing it myself, even i don't use it, openrc should avoid depend on gentoo choice, else named it gentoorc.
You have state your support kernel list is the one support by kernel.org, while i'm still considering this a restriction for no real reason (not because you must add thing to support them, but you are trying to remove thing to no more support them here, making that reason, kinda weak for me), let's say this is an not that bad limit still.
But kernel.org have an 2.6.32 lts...

While i get the idea of Patrick Lauer that removing obsolete code can only make things better ; if the code is not obsolete, you are dealing then only with optimizing code for some speed up.
And the block itself is ignore on newer kernels, making the speed optimization decision shortcut to : i will drop older kernel support in order to get speedup because i remove ONE <if> test -> if [ -d /proc/bus/usb -a ! -e /proc/bus/usb/devices ];

You think it's worth openrc drop older kernel support to remove an <if> test?
Comment 14 William Hubbs gentoo-dev 2015-04-20 14:54:55 UTC
(In reply to nobody from comment #13)
> (In reply to William Hubbs from comment #12)
> > > # Make sure we insert usbcore if it's a module
> > > if [ -f /proc/modules -a ! -d /sys/module/usbcore -a ! -d /proc/bus/usb ];
> > > then
> > >        modprobe -q usbcore
> > > fi
> > 
> > This test appears to be wrong  because /proc/bus/usb does not exist for
> > modern kernels. I don't know when it went away, but I'm running 4.0.0 here
> > and that directory does not exist even when /sys/module/usbcore does.
> > 
> You are hard to follow, really.
> This test is wrong on modern kernels but good for older ones supporting usbfs
> I'm fine you remove the check to not load usbcore module at all and leave
> that to user/udev(& co), fine if you remove it to unconditionaly load
> usbcore...

I'm going to have to hold off on doing this for the current release because the modules service needs to be moved to sysinit first to support a situation where someone is not using udev or eudev.

> You should first decide if you support older kernel and their scheme to
> handle usb, as i already said, i'm not for removing it myself, even i don't
> use it, openrc should avoid depend on gentoo choice, else named it gentoorc.
> You have state your support kernel list is the one support by kernel.org,
> while i'm still considering this a restriction for no real reason (not
> because you must add thing to support them, but you are trying to remove
> thing to no more support them here, making that reason, kinda weak for me),
> let's say this is an not that bad limit still.
> But kernel.org have an 2.6.32 lts...
> 
> While i get the idea of Patrick Lauer that removing obsolete code can only
> make things better ; if the code is not obsolete, you are dealing then only
> with optimizing code for some speed up.
> And the block itself is ignore on newer kernels, making the speed
> optimization decision shortcut to : i will drop older kernel support in
> order to get speedup because i remove ONE <if> test -> if [ -d /proc/bus/usb
> -a ! -e /proc/bus/usb/devices ];
> 
> You think it's worth openrc drop older kernel support to remove an <if> test?

This change would not really _DROP_ support, it would just mean that you need to mount usbfs yourself if you need it. You could do that by putting a line for it in fstab.
Comment 15 William Hubbs gentoo-dev 2015-04-20 15:48:47 UTC
After conversations on IRC and further research in the kernel source, I have found that usbfs was considered deprecated, even in Linux-2.6.32. That tells me that we  should be able to remove the support for automounting usbfs.

Also, since the modprobe was there to support that automounting, now I do not see a reason to keep it either.
Comment 16 William Hubbs gentoo-dev 2015-04-20 16:43:58 UTC
There are two commits related to this bug as shown below:

4c51324 - removes the automounting of usbfs
95ed066 - removes the loading of usbcore

These will be part of OpenRC-0.14.