tags:

views:

558

answers:

2

I'm writing a PCIe driver/module for a custom device. Since the device is hot pluggable, it can disappear at any time.

Here how I setup up the pci_driver structure:

struct pci_driver my_pci_driver = {
  .name = "my_pci_driver",
  .id_table = ids,
  .probe = "my_pci_driver_probe",
  .remove = "my_pci_driver_remove"
};

But I don't know how to correctly handle the remove event. When the .remove function is called, I have several processes that have handle opened with the driver and performing several ioctl.

So what is the correct way to handle remove of a device ? How can I safely wait for currently running ioctl to finish and then properly remove the device from my driver?

A: 

This is very broad question. You need to design you code in the way that will support device removal. You can take an example from any usb driver /usr/src/linux/drivers/usb/... which is removable by nature.

Comment response:
No it's not, USB subsystem is not responsible for synchronization in your driver. There is a lot of ways to synchronize ref count you can use interlocked operation or use a spinlock or ...
There is a good document describing synchronization primitives on Windows, the terminology is a bit different but the concepts are same, so i recommend.

Ilya
That's what I did but I think it is handled by the USB layer of the kernel, not the driver. My first thought was to use a reference counter on my object handled in ioctl(). When the counter is equal to 0, then it is not used by an opened handle and I can safely remove the device. But I didn't find a way to properly wait for reference counter to become to 0 (a kind of reverse semaphore, something that lock until its value is not equal to 0).
A: 

Because the hardware is removed does not mean your driver is removed. So you need to know wether your hardware is there or not.

Then you should end all running transaction. This means whatever operation you are doing in your file operations, it should at some point end and return with an error code, that you can return to the user code. For USB devices, there is a function doing this for you.

User space code is able to do read/write/ioctl after your device has been removed. These system call knows the hardware is not there anymore, so they should return an error code.

Any sane application will then exit or close the corresponding file descriptor. So refcounting should take place in open/release method. Whatever resource you have allocated, they can still exist after your device has been removed.

shodanex