Skip to main content

UDEV Simple Rules For Events In Linux

By
How to execute external program upon certain events occurred in linux?
This is quite wide requirement if you are running embedded linux on target board. Well The answer could be varied as question is more general. Lets limit the scope of question to USB devices.
Running external programs upon certain events to be specific want to run a program on USB device connection and on USB device removal.
Well I am going to do it with UDEV,
For the beginners/novices about UDEV and howto write UDEV rules the howto is pretty nice and easy to apply. udev plus tux, from the udev page
One can do it with signals also, but I like this way. To start with,
I have written simple udev rules file and kept in /etc/udev/rules.d/90-local.rules (off course you can give any name but with ext .rules and start with some no like 90 here); My udev rules are in 50-udev.rules files which defines the way to mount on USB connection and unmount on USB device disconnect.
I can't believe myself that with simple two lines rule placed in 90-local.rules file my job is done;
Here is 90-local.rules file

KERNEL=="sd*[0-9]",ACTION=="add",RUN+="/usr/sbin/usb_detect"

KERNEL=="sd*[0-9]",ACTION=="remove",RUN+="/usr/sbin/usb_detect"

These two line says on connection of disconnection run the local file ie kept in /usr/sbin/.
You can write whatever you want in this exe; I am creating a default share on USB detection and making it to available for others to see the USB contents. On device removal I am deleting the shares.

The functionality introduced here allows you to run a program after the device node is put in place. This program can act on the device, however it must not run for any extended period of time, because udev is effectively paused while these programs are running. One workaround for this limitation is to make sure your program immediately detaches itself.

Here is an example rule which demonstrates the use of the RUN list assignment: 

KERNEL=="sdb", RUN+="/usr/bin/my_program"
One observation if you enable printf inside your my_program you will not get the output on consol. Don't get panic, rather read the UDEV howto.
Labels:

Comments

Post a Comment

Popular posts from this blog

Dotnet, .Net 3.5, 2.0, C# Interview Questions

By
Few questions on dotnet, C# 2.0, 3.5 On Object oriented concepts 1)What is inheritance with e.g 2)What is polymorphism -function overloading -Function overriding -virtual keyword use -Static keyword and use -Abstract classes -Interface -Object 3)What is threading and how do we use in realtime application(cognizant) 4)What is threadpooling, lock, monitor(write code sample) 5)Architecture of current project 6)Session state, diffrent types of state management. 7)What is Application_Start, how it works. 8)Type of authentication in asp.net 9)How to configure ASP.NET application. 10) What is Impersonation. 11) What is WebService, WSDL, UDDI, Discovery, asmx files. 12) How to implement WebService and use it. 13) When to use WebServices. 14) WPF, how to implement(BOA) 15) Testing concvepts. 16) Test attributes 17) Flow of Automation Test Method execution 18) Features of dotnet 3.5 19) CLR, garbage collection 20) Finally block 21) Manifest, Metadata, MSIL 22) Assemblies, Type of assemblies, str...
2 comments
Read more

Remote debugging for ARM target board

By
Remote debugging for ARM target board With GDB one can both trace and modify code and data flow, and otherwise analyze the behavior of code, without explicitly changing any of it. Rather than run a full-blown instance of GDB on the target platform, you can use GDBserver , a program that lets you run GDB on a different machine than the one on which your program is running. The advantage of using GDBserver is that it needs just a fraction of the target resources that GDB consumes, because it implements only the low-level functionality of the debugger -- namely setting breakpoints and accessing the target processor registers and read/write application memory. GDBserver takes control of the application being debugged, and then waits for instructions from a remote instance of GDB running on a development workstation. Remote target needs to have debugging stub (gdbserver), The gdbserver is also referred to as the 'stub' and must be cross-compiled for that targ...
3 comments
Read more