login
Search
Dear all,
I'm looking for a bit of help regarding a 2.6 driver I am working on. The driver is a simple usb device that creates a unique proc entry for controlling each device (e.g. /proc/deviceN_ctrl). This works fine until the device is removed by unplugging the cable, while in use.
Under these circumstances the remove_proc_entry fails as there is still an active reference count on the device. Is there any way to kill all active users of the device. It seems that the linux driver architecture relies on user-space apps to be notified by the driver, when a device is removed. How do I do this?
The /proc/ctrl approach to controlling a device from user-space seems to be quite common (e.g. all video for linux devices do it), but I cannot find any other code where this situation is handled, all seem to accept that all references will be closed by the time the device is removed.
Any help welcome
Cheers
Oliver
I will preface this by saying
I will preface this by saying that I do know a bit about device drivers in Linux, but I have not worked particularly on USB drivers. Take that as you will.
I think that you might be taking the wrong approach here. Generally, using /proc to control new devices is frowned upon by the kernel community; they are trying to move away from that. Depending on what your needs are, you probably either want to use an ioctl, or some files in /sys.
However, if you need to use /proc, I'm not sure that I entirely understand your question. Are you saying that when you have active processes using the /proc/deviceN_ctrl file, then you can't manually remove the module (using rmmod)? Is your kernel oopsing because of the remove_proc_entry failing? Since these are USB devices, it seems like you should be able to solve the problem of active processes by putting the right stuff in the /etc/hotplug scripts.
For reference, there is a discussion of USB devices and how they interact with the kernel (written by the USB maintainer) in the O'Reilly book Linux Device Drivers, Third Edition. I highly recommend the book; it has helped me with a number of issues in the drivers I work on.
The fact the it is a USB devi
The fact the it is a USB device only implies (unlike most PCI card) that it can be hot-plugged but is infact irrelevant to the problem. The problem is that remove_proc_entry does not work if there is an active reference count for that device.
For usb the /proc/ctrl style files work very well, better than mknod in /dev, as you can have a huge amount of hubs & devices all hot-plugging. If you then create a /proc/ctrl entry for each device as it is plugged in, you have a simple means of enumerating and accessing all of your types of devices that are plugged into the system. Unlike the mknod approach where you may end up with lots of unused or non-existant /dev files. The /dev approach is a bit too static for me, though that is personal preference for sure.
A device that is unplugged could still have a user-space app with an open reference to that device (doing icotls and what-not). To be able to remove the /proc/ctrl entry for that device, I need to be able to knock off all the open file-descriptors to it in user-space. And that's my question, I guess, how can I force all user-space file references to close?
I have considered other approaches, and this for now seems the most practical, if I can solve this problem one issue.
Cheers
Device enumeration
Device enumeration in 2.6 is done using /sys
Surely the same thing happens
Surely the same thing happens if the control file is in /proc or /sys. If you try to remove the control file while a user-space app has it open, then things like remove_proc_entry will fail.
One way that might work is to set the fops member of a usb_device's device member to the fops that are currently being done through the /proc/ctrl node. Though it may just "pass the buck". How would you access that device though (Sorry, this is where my linux knowledge becomes a bit purple and hazy)?
no..
The developers are not sleeping.. Just use the interfaces you are supposed to use. The sysfs and kobjects are designed to work in this situation, e.g. properly refcounted to be freed when the files are closed 'too late'. See http://lwn.net/Articles/31185/ and follow the links from the overview chapters to the description.
Ok, that fixed the problem. I
Ok, that fixed the problem. If I use a /dev/inode entry to control a device instead of a /proc/inode entry (using usb_register_dev and usb_deregister_dev) the problem doesn't seem to happen. Odd, you would think that the underlying inode mechanisms would work the same; obviously not.
Cheers for help
NB: I wouldn't dare imlpy that the developers are sleeping :-)./