There is a kernel driver sending events to an application. This is done using a procfs file that blocks on read until a new event must be reported. The application reads this file and gets blocked until there is new information.
This approach works but doesn't look nice to me.
Now I found uevent as a notification mechanism that seems to be used for this purpose.
But it seems to do much more than just that. I read about hotplugging devices, registration of devices and so on and I need to register a kobject to do that. All this makes me unsure if uevent is too excessive for simply sending a short message from one driver to a dedicated userspace application.
Is a uevent the appropriate means for what I want to do or is it too much overhead and I should use something more simple?
By the way I am trying to find a good example how to use uevent as a notification only. Is there something understandyble that doesn't focus on all the mentioned other features?
Related
Difference between an API and a device driver
From the above link i read that API is like a specification that describes what to do, while a driver is an implementation that describes how to do it.
Now, i couldn't find API in linux for display, audio etc.I have also read on internet that linux provides device files to interact with device drivers. we can communicate to devices by writing or reading in those files but as written above API is the specification that describes what to do and API layer is missing here.so, i don't know what commands to writes in those files to interact with devices. ex-rasterize a image on display with the help of these device files.
Device files are just a practical way to communicate between user space and the kernel. Some device files (most notably, block devices) have a uniform API to them, but that's kinda besides the point.
For most standard operations, you would not interact directly with a device file, but instead use a library, exposing a documented API, for doing what you want. So, if you want to play sound files, you'll use, e.g., libjack, or even a higher abstraction layer, such as gstreamer or libvlc.
It is possible, and even likely, that those library use a device file for their actual output. You need not deal with that, unless you want to.
In other cases, you do want to open the device file and interact with it. In those cases, you need to read the relevant documentation to see how to do that. Some device files merely accept read and write requests. Others, such as tty devices, have ioctl commands that modify how they work. The man page for the relevant device will tell you what you need to know.
In general, many treat device files as extension of the kernel's API. In fact, many call the ioctl command "user defined syscalls". In all cases, just read the documentation to see what you need to do.
I am working on a simple project that (as I would like it to be) monitors a uevent for just one possible device and then receives data from it. I am using this on eLinux ported on a BeagleBone Black. Now, I know udev does exactly that albeit for every possible device. I wanted to know if would be possible to write a userspace program that listens to just this uevent and takes appropriate action.
for Linux, there is a nifty little library called xbindkeys that (surprise) binds commands of your choice to certain key combinations.
I am looking for something similar, except for a system hardware event. When I plug in my headphones to the output jack on my computer, I would like to be able to call a program. It would also be nice to be able to bind to the event when I un-plug my headphones.
Does anybody know if this is possible? Maybe through some cool Python X11 library?
Thanks in advance.
EDIT: Found the API for the jack abstraction layer: http://www.alsa-project.org/~tiwai/alsa-driver-api/ch06s02.html
Sadly, this only allows for polling of the device, not an event handler.
You probably want to use udev for this. I haven't used libudev, but here's something I found:
libudev - Monitoring Interface
libudev also provides a monitoring interface. The monitoring interface
will report events to the application when the status of a device
changes. This is useful for receiving notification when devices are
connected or disconnected from the system.
The actions are returned as the following strings:
add - Device is connected to the system
remove - Device is disconnected from the system
change - Something about the device changed
move - Device node was moved, renamed, or re-parented
That article goes on to show how it obtains a file descriptor via udev_monitor_get_fd, which it later monitors via select.
Most modern Linux desktops (notably Gnome and KDE) use "DBus".
DBus, in turn, utilizes HAL (older) and/or udev (newer).
Here are a couple of links that explain further:
https://www.linux.com/news/hardware/peripherals/180950-udev
http://w3.linux-magazine.com/issue/71/Dynamic_Device_Management_in%20Udev.pdf
http://dbus.freedesktop.org/doc/dbus-tutorial.html
I have a question regardind dbus on the current(2.6.35) kernel. Is dbus a way of communication between kernel and user space? I can figure it out by myself. For exemple if you make use of the usb driver(inserting something like a usb flash pen) and monitoring the activity of the dbus(dbus-monitor) the answer might be yes. But in the source code(usb-skeleton.c and the driver for gadgets there's no sign of dbus). Dbus.h is not to be found in the kernel tree.
Thank you very much. Sorry if i've got this wrong but i am kind of a noob on device drivers and dbus!
D-Bus is for user space applications to communicate with one another.
If you want to communicate with a device driver you want to use either IOCTLs, netlink or create a new syscall. I've created netlink code in the past to speak to a special networking card, and it was relatively easy to do. Using the ioctl is also quite easy but you are limited by how much information you can/should pass via it.
If you are curious how dbus relates to a USB device being inserted, I think it is something like this:
D-Bus (or "daemon bus") is a means of communication between processes (inter-process communication or IPC for short) on Linux/Unix based systems.
It lets processes expose a "D-Bus service" with methods that clients can call. These methods usually map to real methods written in some programming language. D-Bus is language-independent, but most toolkits have some library to make it easier to use - e.g. QtDbus.
It is in no way related to the kernel or drivers, but of course no one prevents a driver from also having a D-Bus service if they want to. (This could be useful in some cases.)
I am learning programming in embedded systems using Linux as my main platform. And I want to create a Device Event Management Service. This service is a user-space application/daemon that will detect if a connected hardware module triggered an event. But my problem is I don't know where should I start.
I read about Netlink implementation for userspace-kernelspace communication and it seems its a good idea but not sure if it is the best solution. But I read that the UDEV device manager uses Netlink to wait a "uevent" from the kernel space but it is not clear for me how to do that.
I read about polling sysfs but it seems it is not a good idea to poll filesystem.
What do you think the implementation that should I use in my service? Should I use netlink(hard/no clue how to) or just polling the sysfs(not sure if it works)?
Thanks
Yes, polling is ill-advised. These resources: LJ article on Netlink, "Understanding and Programming with Netlink Sockets" make it seem not so hard to do netlink. Here's an example of netlink sockets in python.
udevtrigger is a great utility for reacting to udev changes.
http://www.linuxjournal.com/article/7356
http://smacked.org/docs/netlink.pdf
http://guichaz.free.fr/misc/iotop.py
http://manpages.ubuntu.com/manpages/gutsy/man8/udevtrigger.8.html
If all you do is wait for an event you can use sysfs, which will be a lot simpler than netlink. An example is the GPIO system's edge file.