I am a bit confused with the questions listed below:
While I execute udevadm on my desktop, it is able to listen uevent sent from kernel.
I think before the execution of udevadm, it will check the availability of udevd.
That means, if the udevd is not available on my desktop, udevadm will not be able to work.
Is my thinking correct?
To have the same functionality of udevadm, I found that linux also provides another way
to archive this. It's called netlink. What confuses me is If I do things this way, I could have exactly the same thing that I have by using udevadm. Hence, what's the difference between udev vs. netlink socket?
socket(PF_NETLINK, SOCK_DGRAM, NETLINK_KOBJECT_UEVENT); <----The socket I created to listen to uevent.
Thanks for avd's feedback. I still have some questions to ask after having your feedback.
There are not only udevd can listen message from kernel, but also udevadm does.
Is my thinking correct? Or udevadm is only to manage udevd.
By setting up the socket binding to the NETLINK_KOBJECT_UEVENT, the user space code can also listen uevent sent from kernel. At this point, It seems I have no reason to choose udev to complete this function. Is there any different between these two approaches?
In user space, Can two different processes listen to uevent simultaneously? Can netlink send the message to these processes in the same time?
Yes, you're right. udevadm is to manage udevd.
This is where you're really confused. Let me clarify this. udev is userspace device manager. udev is responsible for your devices to appear in /dev directory. It's also responsible for hotplug functionality. To make things done udev works by receiving messages from kernel. Kernel sends messages via netlink socket. Netlink is just IPC facility implemented as separate socket family specifically for kernel to userspace interaction. So kernel sends messages of special format (uevent) over netlink socket. On the other site (in userspace) there must be someone who is listening for this messages and that's what udev does. Main part of udev is udev daemon - udevd. That daemon listens for that messages and creates special device files under /dev path and provide to you (linux user) interface to manage devices and hotplug (udev rules).
I've answered related question - check it here.
Extra answers:
From udevadm manpage:
udevadm expects a command and command specific options. It controls
the runtime behavior of systemd-udevd, requests kernel events, manages
the event queue, and provides simple debugging mechanisms.
So it's just a managing tool though it can requests kernel event on admin command.
(I might not understand you question correctly). You can write your own daemon to listen for uevents. That's what gentoo's mdev does.
Netlink allows you to provide multiple listeners for netlink messages. But it depends on a way that kernel socket sends message (unicast, multicast, broadcast) and netlink family. Netlink itself is a collection of families, so it may depends on what netlink you are using. For example, NETLINK_GENERIC family allows you to bind multiple userspace sockets for messages and you will receive that messages. I think the best way to answer this question is to write some simple listening code (probably with some help of libudev)
Related
I need to detect when a USB serial device is plugged or unplugged on my embedded system and know what is the tty associated with it.
My system runs over a 2.6 Linux Kernel.
Since I don't have write access to udev rules, nowadays I'm trying to get this information from the file system, looking for modifications in /sys/bus/usb/devices directory. However, I'm facing some problems with this approach.
I know what is the Id BUS of the USB port connected (e.g 1-1.3). So, I search for the associated tty (looking for a directory in /sys/bus/usb/devices/<Id BUS>:1.0/tty/ - e.g. /sys/bus/usb/devices/1-1.3:1.0/tty/ttyACM0). This way I know that I should use /dev/ttyACM0 to communicate with my device.
But, sometimes, this device (/dev/ttyACM0) does not exist.
Is there any better way to get this information?
I even thought trying to get this information from the syslog, but I don't know whether this is a pretty good idea.
Edit:
Only to clarify, my system needs to be able to detect state changes in the USB bus, i.e. detecting when a new device is plugged (and getting the tty name linked to it) or an existing one is unplugged.
The system is monitoring up to N USB/serial devices, which are plugged to it using an USB HUB. During its normal execution new devices can be plugged, existing devices can be removed (or rebooted by a remote command - out of this scope). When a device is rebooted, it could receive a different tty from the previous one used before (e.g. ttyACM0 -> ttyACM3), since the kernel designates to it a tty which is free at the moment, and it is a big problem to me.
Netlink is the preferred mechanism for communication between kernel and userspace.
You would create a Netlink socket with family NETLINK_KOBJECT_UEVENT, listen on that socket and filter out messages that contain SUBSYSTEM=usb and ACTION=add for USB plug events or ACTION=remove for USB unplug events.
I wrote a USB abstraction library called libusbp. You should look at its port_name example, which shows how to use libusbp to get the serial port name (e.g. /dev/ttyACM0) for a USB serial device. Behind the scenes, libusbp gets this information using libudev.
Check if the virtual file is deleted using stat.
#include <sys/statvfs.h>
...
struct stat sb;
return (stat("/dev/ttyUSB0", &sb) == 0); // true if open, false otherwise
I need to display the status of the ethernet connection (eth0) on the GUI, i.e. is the link up or not.
I have a Davicom DM9000 PHY.
I know there are various ways to skin this cat, like parsing ifconfig, polling /sys/class/net/eth0/operstate, etc.
However, as I will need to monitor other devices also, like USB, I would like to use libudev for this as a more generic implementation.
Furthermore, I would like to use the monitor mechanism (using a select() ) and in doing so prevent having to poll.
I have wrapped the libudev functionality in a Qt class and intend on using signal/slot mechanisms to indicate events to my program.
Problem is, I can't seem to generate UDEV events from eth0 no matter what.
I have also tried using
udevadm monitor
but no events either when unplugging my ethernet cable.
I don't think my code is too far off, because I am able to generate events for USB (hidraw) devices by unplugging my keyboard, for example.
Also, I am able to see eth0's attributes using the libudev enumerate mechanism (but this is a polling process)
My question - is this possible, i.e. to use libudev's udev_monitor functions to catch events on eth0?
Sorry for the long post.
Have already looked at D-bus? Via D-Bus and underlying services you can get all the info you need. See this a little bit outdated article to understand the concept. See Qt/D-Bus documentation.
I have written a user-space program that polls for the status of the available Ethernet interfaces for their operational status using netlink sockets with NETLINK_ROUTE protocol.
But now I want to write a kernel module which uses the NETLINK_ROUTE channel to send customized notification message to this user-space program.
After reading the man page for netlink and rtnetlink I cannot conclude if it is doable. Any suggestions will be highly appreciated.
NETLINK_ROUTE is not a protocol - it's one of the netlink families. From manpage:
netlink_family selects the kernel module or netlink group to
communicate with.
Netlink was initially developed for fast and easy messaging about routing info and that's why NETLINK_ROUTE is first family and have own manpages, manuals, etc. But later other families were added to send other than routing info, e.g. NETLINK_SELINUX and NETLINK_FIREWALL.
After some time developers saw that there are way too many specific families. If somebody wants to use that fancy netlink protocol he needs to declare another family and make it even worse. So they added last family - NETLINK_GENERIC that works like multiplexer. There is a great manual about generic netlink on lwn - http://lwn.net/Articles/208755/. If you want working examples you can look at my code (https://github.com/dzeban/keymon)
So, if your notifications related to any specific netlink family like NETLINK_ROUTE - then use it. But if you want to just send your very own and custom info - use generic netlink.
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.