udev rule, when RUN script is invoked?

[greg@kroah.com (Greg KH)]

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@kroah.com> 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?

> > 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.

So there's no real need for the udev rule here.

hope this helps,

greg k-h