On Thu, 22 Feb 2018 18:05 +0100, Greg KH <greg@xxxxxxxxx> wrote: > On Thu, Feb 22, 2018 at 08:44:20AM -0800, Alexander Ivanov wrote: > > Greg, > > > > On Thu, 22 Feb 2018 08:56 +0100, Greg KH <greg@xxxxxxxxx> wrote: > > > On Wed, Feb 21, 2018 at 03:36:44PM -0800, Alexander Ivanov wrote: > > > > Hi All, > > > > > > > > I have udev rule defined on a > > > > > > > > DEVPATH="/dev/mydev0",..., ACTION="remove", ..., RUN+="/path/to/script" > > > > > > > > When does /path/to/script is executed in respect to module's remove() and exit() ? > > > > > > A module's lifecycle is different from a device's lifecycle, right? > > > > > Sure. However, in this particular case, only one device for the module > > can exist and user-land calls insmod/rmmod, Thus, on rmmod both > > device's remove() and module's exit() are getting called. > > What type of crazy "device" is this? Have a pointer to the source code > anywhere? > Why crazy? :) This is char device that is created by pcie driver. PCIe device has a channel to dump some debug information over to the host. This char device is an interface to that debug data. It's just a little addition to main pcie driver to help hw/fw development > > > There is no remove() call for a module, only for a driver subsystem, so > > > be careful as to what exactly you are referring to here. > > > > > > Hopefully, all devices "owned" by the module should be removed from the > > > kernel before the module is unloaded, so that should help you out here. > > > > > > Also note that modules are never automatically unloaded, so that is > > > never a normal operation in the system. > > > > > > what exactly are you trying to do here with your udev script? > > > > On action=="remove", I'd like to call device's close(), it was open()ed by action=="add" > > It looks like device is removed before RUN gets a chance to execute.. > > Of course it is, because when the module is removed, you already removed > the device, right? > > > Basically, I need to start reading from device as soon as it appears > > in the system, and stop it right before it get removed. > > "right before" is hard if you don't tell your userspace program you are > going to remove the module :) > > Your program should be able to handle the device node being removed > underneath it anyway, there's no need to have to "stop" the program, it > can easily detect if the device goes away. > Sure custom code can do it, no problem. I though I could just use simple cat /dev/dbg0 > file, and then kill it . anyway, thank you for explanation. --Alex > So there's no real need for the udev rule here. > > hope this helps, > > greg k-h > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies@xxxxxxxxxxxxxxxxx > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Alexander Ivanov amivanov@xxxxxxxxxxxx _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
