On Thu, Feb 22, 2018 at 09:35:30AM -0800, Alexander Ivanov wrote: > > > > > 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 But that PCIe driver binds to an actual device, right? So you could have multiple devices, your char device lifecycle should be tied to the pcie device you are talking to, not the module code lifecycle. Again, code has a different lifecycle than data. Data is assigned to a device, and your code acts on that. Anyway, just be careful here, don't get the two mixed up, we did a lot of work 15+ years ago to separate the lifecycles to be sane and work properly in modern systems (i.e. dynamic systems where everything can be removed and added at any point in time, no matter what your code is doing.) > > > > 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 . If this is debugging stuff, why are you using a char device node? That's what debugfs is for. And your 'cat' instance should shut itself down automatically when your device goes away, _if_ your driver is working properly :) good luck! greg k-h _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
