Originally Posted by
jeffcobb
I *will* make it work. In truth it is not high-priority for the project I outlined above but it is the principle of the thing. Besides, MP3 players do this all the time
An mp3 player is exactly the same thing as a usb key drive -- in fact, AFAIK there are no specific drivers for mp3 players under linux since you can access them just fine as a drive. But this is a far cry from linking two hubs together.
Ie, an mp3 player is totally dissimilar to another computer's usb port.
and as I may have may have mentioned, Macs can do this (plug one Mac into another via USB and one becomes a slave/drive). Used for backups and such...
As Kennedy hinted earlier, this is done with a special cable, you can watch a video about it here:
Targus For Mac File Share Cable Direct connect adapter - Hi-Speed USB
They do look almost like a normal usb cable, but there are electronics "hidden" in it at one end and software is involved. So you might be able to write a linux driver to interact with this device, but probably that will not be much fun (even: impossible) unless you get some details about how the interface works from Targus.
If you really want to try using a regular cable (ie, something that probably has not been done by anyone with any kind of computer) inquire to the kernel-dev mail list to find out who to contact about the usb hub driver and ask them if this is (even theoretically) possible using the current kernel hub driver (I think it is not, but).
The kernel can load (or autoload) usb drivers based on the device id they show when plugged in (this is what you can find under lsusb). You need to register those with the kernal, eg:
Code:
#define VENDOR 0x0c45
#define PRODUCT 0x612a
If you plug a device in for which there is no known driver, nothing happens. Since a usb hub was not made for a two way relationship, I doubt plugging one into another will show anything (again, if you can find a male male usb cable you can check). There will simply be no communication at all. There will be no vendor and device id show to register anything. And unless you have a device attached to the hub, there is no way to "send" anything thru a specific port (notice, they are not numbered hardware interfaces like serial ports; on a low level, you deal with the hub and not the ports -- this is a 100% hardware relationship managed by the hub, not the OS. The OS's relationship ends at the hub). So you could not "spoof" a vendor/product id from the other end by "choosing" to send some signal thru a specific usb port. The ports do not exist on a software level, only the hub does.
You'd be better off considering the serial ports (or, obviously, the ethernet) for this since I think you will have to write a whole ton of software to represent the filesytem across the interface anyway, and that will be more or less the same. Ie, this is basically a version of NFS.
You could write a kernel driver to create a non-physical device to work with such software (I think that's what NFS does), that is, the "device" will actually be an interface with the ethernet connected software.