How to programatically detect when a device raises an interrupt? This can be when a device is connected or disconnected.And also this case: for example: when a finger is held over a fingerprint scanner, an interrupt is raised. How to detect and possibly trap this interrupt?I want to write an application using Gtkmm such that when an event occurs like a CD being inserted or a pendrive being plugged in, I catch the interrupt these devices raises and use it to do something in my application, involving these devices. If it cannot be done in Gtkmm, can I trap the Interrupt at a lower level and inform the Gtkmm application?I was checking out how GParted behaves. It was initially showing /dev/sda and when I connected my pendrive, it automatically opened files application. When I checked GParted, pendrive was not present in the drop down menu of devices. It appeared only when I selected Refresh Devices in the GParted menu or Ctrl+R.
How to programatically detect when a device raises an interrupt?
linux;devices;signals;interrupt
I can try to trap the Interrupt at a lower level and inform the gtkmm application.No, that is a kernel space activity.  Fortunately, the kernel does report the outcome of certain events via interfaces accessible from userland.It's a little ambiguous in your question whether you want to detect when a block device is attached, or when a filesystem is mounted (although it seems to be more the former).  If your system uses automounting (they usually do by default), it will mount filesystems from block devices when they are attached, otherwise you have to do it manually (e.g., with mount).Either way, you want to poll/parse/scan a kernel file node based interface.  I've done this before in an application (a C++ GTK one, in fact) that tracks both attached block devices and mounted filesystems via /dev/ and /etc/mtab.  This is a straightforward, language agnostic method.  Some people find it a little distasteful at first because it involves reading files/directories, but these interfaces do not actually exist on disk, so there is no heavy I/O overhead, and remember: read() is a system call.  Reading the file nodes in kernel interfaces amounts to the same thing as a listAttachedDevices() style API, except again, it is language agnostic.  When you go to read from these nodes, the kernel passes you the information they represent directly.The /dev directory lists attached devices as special device node files -- e.g. /dev/sda.  These are added and removed by the kernel as devices are plugged in and out, so if you track it by polling at intervals (say every 5 seconds), you can detect what's new and what's gone.  The only complication here is that since there's no callback style API, you have to create your own thread for this if you do want a continuous check (perhaps why gparted requires you to click Refresh Devices instead).A probably better alternative to /dev would be the stuff in /sys/block.  Note that there is a significant difference between /dev and /proc (see below) or /sys  in so far as the nodes in the latter contain information about things such as devices, whereas the nodes in /dev are an actual connection to the device (so if you scan /dev, don't bother reading the individual files, just note they exist)./etc/mtab now-a-days is a symlink (see also the -s switch in man ln) to /proc/self/mounts; /proc is a major swiss army knife kernel interface (see man proc).  This lists mounted filesystems; if you use automounting things will appear and disappear from there when stuff is plugged in/out.  The information in /proc and /sys is usually in the form of ASCII text, so you can look at these files with cat, etc, and parse it with string(stream) functions. WRT to other kinds of devices, such as a fingerprint scanner, /sys is a good place to start -- /sys/dev contains a block and a char directory.  Block devices are usually storage; the information on them can be randomly accessed.  Char devices exchange information with the system in a stream, which would include things like scanners, cameras, HID stuff (human interface device, e.g. mice and keyboards).  I notice that gtkmm does have some high level stuff for attached HID things, presumably since these are significant in interacting with the GUI.