mapping usb device to device file
 

Hello,
I've been searching google for a while now for a way to do this and have come up more or less empty handed. I need to list the usb devices (flash card readers) attached to my computer in my program. The problem is that I can't find a good way to figure out what device file each reader corresponds to. I initially tried dmesg which would give me the device names and tell me it was attached to /dev/sdb or some such, but dmesg is very unreliable when I hotplug a new device in or unplug one. The only file I've found which really gives accurate information about what is actually plugged in is in /proc/bus/usb/devices. Unfortunately, I can't find a way to map the information in that file to /dev/sdb or /dev/sdc. The closest i've foudn is sg_scan and sg_map but sg_map crashes my whole system and sg_scan doesn't seem to work too well with hotplugging. fdisk -l will tell me what disks are mapped to where, but I can't find a correlation to the devices file with the names (I also need to be able to tell that they are actually usb readers).
PS- I'm running redhat 8.
Any help would be much appreciated,
-Scerenon

Why? I don't know remember how the older kernels did it, but nowadays, there is udev which lets you create rules for persistent naming of usb (and other) devices. I'm almost positive that there's also an entry in /proc somewhere.

Consider getting a more up-to-date distro.

I have heard of udev, unfortunately it isn't on rh 8. I need redhat 8 as I need a proprietary app to run on it that only wants to build under rh8. I could try to get it working on newer distros, but it would make my life much easeier if I could just figure out how to solve the device file mapping problem.

Did you check the /proc filesystem?

Thank you for your reply.

I've read through the /proc filesystem and the only file i've found in /proc that is really useful is /proc/bus/usb/devices which I mentioned above. Can you be more specific please?
-thanks

I'm sorry, I don't think the /sys interface is available in 2.4. I thought maybe /proc might have similar information. Can you post the output of devfsd.conf or equivalent.

# Sample /etc/devfsd.conf configuration file.
# Richard Gooch <rgooch@atnf.csiro.au> 3-JUL-2000
#
# Enable full compatibility mode for old device names. You may comment these
# out if you don't use the old device names. Make sure you know what you're
# doing!
REGISTER .* MKOLDCOMPAT
UNREGISTER .* RMOLDCOMPAT

# You may comment out the above and uncomment the following if you've
# configured your system to use the original "new" devfs names or the really
# new names
#REGISTER vc/.* MKOLDCOMPAT
#UNREGISTER vc/.* RMOLDCOMPAT
#REGISTER pty/.* MKOLDCOMPAT
#UNREGISTER pty/.* RMOLDCOMPAT
#REGISTER misc MKOLDCOMPAT
#UNREGISTER misc RMOLDCOMPAT

# You may comment these out if you don't use the original "new" names
REGISTER .* MKNEWCOMPAT
UNREGISTER .* RMNEWCOMPAT

# Enable module autoloading. You may comment this out if you don't use
# autoloading
LOOKUP .* MODLOAD

#
# Uncomment this if you want permissions to be saved and restored
#REGISTER .* COPY /dev-state/$devname $devpath
#CHANGE .* COPY $devpath /dev-state/$devname
#CREATE .* COPY $devpath /dev-state/$devname

Oh yes, and I do have the /proc/sys folder if that's what you meant, it contains the following:
abi, debug, dev, fs, kernel, net, proc, vm

No that's not the same (/sys != /proc/sys). The `/sys' folder is part of the new kernel device scheme (along with udev) which is only for 2.6 kernels.

Right now, (as I'm in the process of digesting your conf file,) I'm trying to remember how devfsd worked. I'm pretty sure that's where you'll find the answer to your problem, I'm just a little rusty on the details (it took me so long to become comfortable with udev!).


P.S.
Are you sure you want to continue with the old distro? You might be able to build or run the proprietary app on newer distros just by downloading a bunch of `legacy' libraries and old versions of gcc, etc., etc (unless your app is closely tied to the kernel). Your best bet might be to get a nice shiny new distro, and load your old setup as a virtual machine (I hear that's all the rage these days). The purpose of the virtual machine would be run only your prop. app.

Actually that's exactly what I'm doing. My app launches vmware in the background to run the program in linux as I was tasked to get it working on windows ( I communicate with the linux distro through the virtual network). The person that originally worked on it has suffered some health problems so changing anything or building a new one on windows would take more time than I have as I am not very familiar with it. It's kind of a clunky solution to be sure, but it's working for the most part... aside from the fact that I always assume the device file is sdb which isn't always the case.
I will take a more in depth look at devfs and let you know if I find anything, kind of depressing that someone couldn't have made a simple app like this 6 years ago though on linux, there must be a way that doesn't involve hacking the kernel.

If you're running a linux distro on a virtual machine in windows, why do you need usb hotplugging to work? Just wondering.

I list the devices with names to the user in windows, and then they can select one to operate on. So the windows app just queries the linux one for a list of devices, user selects the name they want ( like imagemate 6 in 1 64mb) and linux does the operations on it. If someone were to have an external harddrive plugged in and then plug in a usb card and my program incorrectly used the wrong device file and formatted their external hard drive, it would not be good to say the least. Of course they could just use linux directly, but that is not up to me.

I figured it out! ... mostly.
I was having trouble to get devfs to work correctly. I found out that it was incorrectly built into the kernel, so i tried recompiling the kernel with /dev support enabled but I kept getting errors with it on make install.
The solution I found without devfs was to use a combination of /proc/bus/usb/devices and /var/log/messages as they both list the "device number". varlogmessages will tell me what devices number was assigned to what product, and then further up it will tell me when the product was first plugged in what device file it was plugged into.