On Sun, 16 Feb 2003, Brad BARCLAY wrote:
>On Sun, 16 Feb 2003 19:43:57 +0100 (MET), Aurélien GODIN wrote:
>
>>I guess a better solution would be to deactivate "hotplug" when launching the java
>program by passing
>>the appropriate command to the system using the Runtime class,
>Runtime.exec("deactivating hotplusg package"),
>>and reactivate it when exiting the virtual machine. However, I didn't find the shell
>commands
>>that enable to do that. Any idea ? Anyway, uninstalling "hotplug" is acceptable if
>you do not normally
>>use USB devices with Linux.
to disable hotplug, just do
echo "/bin/false" > /proc/sys/kernel/hotplug
or use /bin/true, it doesn't matter too much. /bin/false may get you
an error or warning message in the kernel logs.
You can re-enable hotplug by doing
echo "/sbin/hotplug" > /proc/sys/kernel/hotplug
or, if your hotplug script is somewhere else, use that. On most
systems it's in /sbin.
However disabling hotplug isn't really a good, or complete,
solution...if the driver is already in-kernel, it doesn't help. Also
if you want some other driver hotplugged (PCMCIA card, PCI-hotplug, or
usb...) it won't happen if you disable hotplug...
> I think an even better solution might be to engage the Linux
>kernel developers in this problem, so that in the future there is a
>programatic mechanism that can be used to flag the hotplug system to
>prevent it from activating for the lifecycle of a specific process for
>a given device ID. The alternative would be to create a specific set
>of Java APIs to interface with the different hotplug modules, and
>that's going to get messy -- and it's going to ruin platform neutrality
>(as you'd wind up programming for this mythical API on Linux, and
>something more generic like Java USB for every other platform).
I think the design point is that hotplug should activate for every
device connection (disabling hotplug is not a good approach), and it's
very configurable. See my responses below...
>
> This issue bothers me on a daily basis, so I spend alot of
>personal runtime contemplating it and potential solutions. Anyone care
>to join me in looking for a solution that we can contribute back to the
>kernel development group?
There is already a USBDEVFS_DISCONNECT ioctl that will disconnect a
driver from a specific interface. That should be all that's
needed...?
As far as using it from Java, I have been thinking about it (as it
affects all the devices I am responsible for also...) and it can be
done via javax.usb in 2 ways, either transparently (from an API POV)
or explicitly. We could add an 'optional' API call to UsbInterface,
like UsbInterface.claim(boolean) where boolean indicates if the
existing driver should be removed (if possible). Or, there could be a
property that, when set, will cause all claim() calls to remove
existing drivers. I like the explicit way, since the transparent way
may cause users to 'accidentally' disconnect all USB drivers on their
system...but the explicit way means adding another API method, which
may not be implementable on all systems. :(
Also, there is another way. The Linux hotplug system is fairly
robust, and while I haven't looked in-depth at it, I'm fairly sure
that it can be configured to ignore specific vendorID/productID
combos. However, hotplug isn't 100% responsible for device<->driver
connections; the kernel probes drivers to see if they want an device,
and stops on the first success. So if the driver you don't want is
already in-kernel, hotplug is not your problem. In that case, the
only thing you can do is disconnect that driver from your specific
interfaces...
All this turns out to not be that bad, except for 1 problem: the UHCI
drivers don't support Control-type queueing in the 2.4 kernel (uhci.c
does starting at 2.5.44 or so). Without control queueing, 2 drivers
(such as the hub driver and any other driver, including usbdevfs)
cannot share the Default Control Pipe. Attempts to do this may cause
control URBs to 'collide' and one of the drivers will fail. If it's
the hub driver, real bad things happen. So, the hotplug script has a
3-second delay built into it, which means usbdevfs (and thus
javax.usb) know about a newly-connected device a full _three seconds_,
OR MORE, before the device's driver is actually connected. This is
plenty of time to connect via javax.usb, and then when the 'real'
driver is loaded in-kernel it will transparently boot you off the
device/interface. Oops!
So, hopefully the 2.4 uhci drivers will soon support control queueing
(I fixed 2.5 and somehow volunteered to backport to 2.4 also...) and
then the above paragraph won't be as much of a problem, if at all...
--
Dan Streetman
[EMAIL PROTECTED]
--------------------------------------------------
186,282 miles per second:
It isn't just a good idea, it's the law!
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
javax-usb-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/javax-usb-devel
