10:42 a.m.
If not, should it be phased out?
I'm referencing a use case with VirtualBox that looks for /proc/bus/usb
by default and will use that instead of libusb for USB device access.
This has caused issues for people wishing to use VirtualBox on Fedora in
that they cannot use USB devices without a little tinkering. They either
have to remove the /proc/bus/usb mount from rc.sysinit or adjust their
fstab to allow other users access.
I'll even go as far as providing a patch! *gasp*
Most of you probably don't care about VirtualBox and would rather us use
libvirt, but some folks use different software.
Mike
10:56 a.m.
2009/7/17 Michael Cronenworth <mike(a)cchtml.com>:
If not, should it be phased out?
I'm referencing a use case with VirtualBox that looks for /proc/bus/usb
by default and will use that instead of libusb for USB device access.
This has caused issues for people wishing to use VirtualBox on Fedora in
that they cannot use USB devices without a little tinkering. They either
have to remove the /proc/bus/usb mount from rc.sysinit or adjust their
fstab to allow other users access.
I'll even go as far as providing a patch! *gasp*
Patch would be welcome. Would make my life easier in #fedora helping
people with that problem.
Most of you probably don't care about VirtualBox and would rather
us use
libvirt, but some folks use different software.
A lot.
--
LG Thomas
Dubium sapientiae initium
3:06 a.m.
2009/7/17 Michael Cronenworth <mike(a)cchtml.com>:
Thomas Janssen on 07/17/2009 10:56 AM wrote:
>
> Patch would be welcome. Would make my life easier in #fedora helping
> people with that problem.
>
The patch should have been attached to the original post. Did you see it?
Ah, overlooked it, sorry.
--
LG Thomas
Dubium sapientiae initium
10:59 a.m.
On 07/17/2009 09:12 PM, Michael Cronenworth wrote:
If not, should it be phased out?
I'm referencing a use case with VirtualBox that looks for /proc/bus/usb
by default and will use that instead of libusb for USB device access.
This has caused issues for people wishing to use VirtualBox on Fedora in
that they cannot use USB devices without a little tinkering. They either
have to remove the /proc/bus/usb mount from rc.sysinit or adjust their
fstab to allow other users access.
I'll even go as far as providing a patch! *gasp*
Most of you probably don't care about VirtualBox and would rather us use
libvirt, but some folks use different software.
Libvirt of course is a library. Even VirtualBox could be using it.
Rahul
11:10 a.m.
On Fri, Jul 17, 2009 at 10:42:56AM -0500, Michael Cronenworth wrote:
If not, should it be phased out?
I'm referencing a use case with VirtualBox that looks for /proc/bus/usb
by default and will use that instead of libusb for USB device access.
This has caused issues for people wishing to use VirtualBox on Fedora in
that they cannot use USB devices without a little tinkering. They either
have to remove the /proc/bus/usb mount from rc.sysinit or adjust their
fstab to allow other users access.
Why not do a patch for VirtualBox to make it look in the right place
first ? We've just done that for QEMU too, changing its search order
to be /sys/bus/usb, /dev/bus/usb and only then /proc/bus/usb. Removing
the whole /proc/bus/usb mount to solve one application's problem does
not seem ideal.
I'll even go as far as providing a patch! *gasp*
Most of you probably don't care about VirtualBox and would rather us use
libvirt, but some folks use different software.
FYI the distinction VirtualBox vs libvirt isn't correct. libvirt is
an API for any virtualization technology, and has drivers for Xen,
KVM, QEMU, VirtualBox and more.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
11:16 a.m.
On Fri, 2009-07-17 at 17:10 +0100, Daniel P. Berrange wrote:
On Fri, Jul 17, 2009 at 10:42:56AM -0500, Michael Cronenworth wrote:
> If not, should it be phased out?
>
> I'm referencing a use case with VirtualBox that looks for /proc/bus/usb
> by default and will use that instead of libusb for USB device access.
> This has caused issues for people wishing to use VirtualBox on Fedora in
> that they cannot use USB devices without a little tinkering. They either
> have to remove the /proc/bus/usb mount from rc.sysinit or adjust their
> fstab to allow other users access.
Why not do a patch for VirtualBox to make it look in the right place
first ?
Because we don't package VirtualBox, because it requires not-in-tree
kernel modules.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
11:21 a.m.
On Fri, Jul 17, 2009 at 09:16:12AM -0700, Adam Williamson wrote:
On Fri, 2009-07-17 at 17:10 +0100, Daniel P. Berrange wrote:
> On Fri, Jul 17, 2009 at 10:42:56AM -0500, Michael Cronenworth wrote:
> > If not, should it be phased out?
> >
> > I'm referencing a use case with VirtualBox that looks for /proc/bus/usb
> > by default and will use that instead of libusb for USB device access.
> > This has caused issues for people wishing to use VirtualBox on Fedora in
> > that they cannot use USB devices without a little tinkering. They either
> > have to remove the /proc/bus/usb mount from rc.sysinit or adjust their
> > fstab to allow other users access.
>
> Why not do a patch for VirtualBox to make it look in the right place
> first ?
Because we don't package VirtualBox, because it requires not-in-tree
kernel modules.
I know that, but that doesn't prevent motivated people sending a patch
to rpmfusion, or virtualbox upstream to solve this problem.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
11:20 a.m.
Daniel P. Berrange on 07/17/2009 11:10 AM wrote:
Why not do a patch for VirtualBox to make it look in the right place
first ? We've just done that for QEMU too, changing its search order
to be /sys/bus/usb, /dev/bus/usb and only then /proc/bus/usb. Removing
the whole /proc/bus/usb mount to solve one application's problem does
not seem ideal.
The VirtualBox developers state:
"/proc/bus/usb is deprecated, and most people have already got rid of
it. If VBox finds it mounted, it uses legacy code to handle USB. We do
this to avoid breaking existing working setups. Otherwise we use newer,
alternative code."
FYI the distinction VirtualBox vs libvirt isn't correct. libvirt is
an API for any virtualization technology, and has drivers for Xen,
KVM, QEMU, VirtualBox and more.
My analogy was poor, yes, as most Internet comments are, but my point
was being VB vs what libvirt provides, not what libvirt is (a library).
11:23 a.m.
Daniel P. Berrange on 07/17/2009 11:10 AM wrote:
Why not do a patch for VirtualBox to make it look in the right place
first ? We've just done that for QEMU too, changing its search order
to be /sys/bus/usb, /dev/bus/usb and only then /proc/bus/usb. Removing
the whole /proc/bus/usb mount to solve one application's problem does
not seem ideal.
Furthermore, my original question still stands:
Does anything require usbfs?
You did not answer my original question.
11:49 a.m.
On 07/17/2009 09:32 AM, Michael Cronenworth wrote:
OK, anything else?
If mkinitrd bites the bullet in the new F12 feature then usbfs could be
deprecated as well?
There's an outside the tree application which breaks when /proc/bus/usb
exists so you want to remove /proc/bus/usb from the tree to work around it.
How do you know there isn't some other outside the tree application that
needs /proc/bus/usb? Asking on this list clearly doesn't prove that
nothing else exists.
I'd argue you're covering up the symptom not fixing the cause.
VirtualBox should fix their code not to use /proc/bus/usb if
/sys/bus/usb exists. They can always add a switch to revert to the old
behaviour should anyone actually need it.
Changing your OS to fix a broken app is always the wrong solution and
that mentality is going to detrimental to Linux in general.
- |Daryll
11:59 a.m.
Daryll Strauss on 07/17/2009 11:49 AM wrote:
Changing your OS to fix a broken app is always the wrong solution and
that mentality is going to detrimental to Linux in general.
You missed the entire point of this thread.
Let me say this so that no one else drags this on:
I could care less about VirtualBox.
If usbfs is globally being deprecated and could be removed, why
shouldn't it? Why are you arguing to keep in old cruft?
12:14 p.m.
Michael Cronenworth <mike(a)cchtml.com> writes:
If not, should it be phased out?
Is there some upstream (linux kernel) discussion to remove usbfs? If
not, it should stay as-is.
I use it regularly because it
a) is accessibly by ordinary users
b) provides more terse information than 'lsusb -v'
c) gives information about used drivers
I'm referencing a use case with VirtualBox that looks for
/proc/bus/usb
by default and will use that instead of libusb for USB device access.
Why not patch VirtualBox to do it correctly?
Enrico
12:22 p.m.
Enrico Scholz on 07/17/2009 12:14 PM wrote:
Is there some upstream (linux kernel) discussion to remove usbfs?
If
not, it should stay as-is.
Fedora/RHEL are the last major distros to retain usbfs support apparently.
Why not patch VirtualBox to do it correctly?
Why not patch your utilities?
Again: The issue is not VirtualBox. I provided it as an example and
people are running away with it. Stop.
12:42 p.m.
Michael Cronenworth <mike(a)cchtml.com> writes:
> Why not patch VirtualBox to do it correctly?
Why not patch your utilities?
You want to change something which is not broken and requests that I adapt
my workflow and spent work into something to retain old functionality?
Again: The issue is not VirtualBox.
VirtualBox seems to be the issue. Or do you have other examples of
software which uses crappy heuristics based upon the existence of
/proc/bus/usb?
Enrico
1:37 p.m.
Enrico Scholz on 07/17/2009 12:42 PM wrote:
You want to change something which is not broken and requests that I adapt
my workflow and spent work into something to retain old functionality?
What about old /dev (pre udev)? It was not broken. Sure, you couldn't
add nice new functionality quickly, but it wasn't broken.
Should we have kept HAL then? Keep using HAL forever?
This type of mindset works until there is a better solution. There are
better solutions to usbfs today. Most distros use the newer alternative.
You ignored my initial comment on this and seem to want to be ignorant
of such a fact.
VirtualBox seems to be the issue. Or do you have other examples of
software which uses crappy heuristics based upon the existence of
/proc/bus/usb?
That particular software does not depend on usbfs, but it seems that
VBox will be a scape goat for your whining until I convince you
otherwise. If you had read the thread beforehand you probably would not
have replied.
Please read the whole thread.
3:41 p.m.
Michael Cronenworth <mike(a)cchtml.com> writes:
> You want to change something which is not broken and requests
that
> I adapt my workflow and spent work into something to retain old
> functionality?
What about old /dev (pre udev)? It was not broken. Sure, you couldn't
add nice new functionality quickly, but it wasn't broken.
Static /dev still exists and works perfectly in servers or embedded
devices. Recent udev did not removed features (as you are requesting)
and its extras seem to outweight its drawbacks (high boot times).
Should we have kept HAL then? Keep using HAL forever?
Dunno; I did and do not use hal on pre FC11 machines.
This type of mindset works until there is a better solution. There
are better solutions to usbfs today. Most distros use the newer
alternative.
There is not needed an alternative. usbfs and the udev/sysfs based
approach coexist nicely.
You ignored my initial comment on this and seem to want to be
ignorant
of such a fact.
Which initial comment? That you want to remove a feature to workaround
bugs in an application?
> VirtualBox seems to be the issue. Or do you have other examples
of
> software which uses crappy heuristics based upon the existence of
> /proc/bus/usb?
That particular software does not depend on usbfs, but it seems that
VBox will be a scape goat for your whining until I convince you
otherwise. If you had read the thread beforehand you probably would not
have replied.
Please read the whole thread.
Sorry; you must be subscribed to another maillist than me. Here, no
article in this thread justifies removal of usbfs with anything else
than the broken VirtualBox.
Enrico
3:46 p.m.
Enrico Scholz on 07/17/2009 03:41 PM wrote:
Which initial comment? That you want to remove a feature to workaround
bugs in an application?
Michael Cronenworth wrote:
Fedora/RHEL are the last major distros to retain usbfs support
apparently.
Sorry; you must be subscribed to another maillist than me. Here, no
article in this thread justifies removal of usbfs with anything else
than the broken VirtualBox.
You're trolling now.
For the last time: This has nothing to do with VirtualBox. There is no
"bug" in VirtualBox. There is no patch required for VirtualBox.
3:50 p.m.
On Fri, Jul 17, 2009 at 03:46:28PM -0500, Michael Cronenworth wrote:
For the last time: This has nothing to do with VirtualBox. There is
no
"bug" in VirtualBox. There is no patch required for VirtualBox.
The bug in virtualbox is that it prefers the deprecated interface over
the current one. There's no pressing reason for us to disable usbfs yet,
and while we'll probably do so eventually I doubt it'll be happening in
F12. We generally prefer not to remove interfaces that may be in use
unless we gain anything by doing so.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
5445
days inactive
5447
days old
20 comments
9 participants
participants (9)
-
Adam Williamson -
Bill Nottingham -
Daniel P. Berrange -
Daryll Strauss -
Enrico Scholz -
Matthew Garrett -
Michael Cronenworth -
Rahul Sundaram -
Thomas Janssen