There are hardware devices which need userspace suppport, like daemon running and handling parts of interaction not suitable (too complex or policy-related) for kernel space.
Running such daemons is easy once you reach userspace -- you can run'em as a result of hotplug event and don't worry much.
Once initramfs comes to the picture, everything suddenly breaks apart: if the daemon is run from initramfs then it needs to either keep running when execution is switched to regular rootfs, which is particularily hard, given initramfs is freed during switch_root or hand out resources and state to another copy of itself, run from rootfs. Both solutions seem inelegant and hacky.
Is there obvious way to manage such devices and their supporting daemons I overlooked?
Do you have a specific case? How have the other distributions handled this?
Looking at how Fedora does udev, it starts it up from the initramfs, gets it to do its stuff so the really root fs can be mounted, then shuts it down again before switching.
Do you need this daemon to mount your real root device ? I guess the answer is yes, otherwise the solution would be to wait for your real root.
I your device is so complicated it needs a daemon to just work, may be you could do part of the job in the kernel, and handle the policy through sysfs attribute ?
I fail to see an example of hardware invlved in mounting the real root deice that would need a daemon to work. Device discovery apply, but you don't need a daemon for the device to actually work. An example would be welcome.
Also, do you really need to switch root ? You could keep your initramfs, and mount whatever you need to have a fully functionnal system under /usr/ That is what I do with some of my embedded system.
Update :
mdev is an embedded alternative to udev, which runsin two mode: on scans sysfs to add device, the other is running for hotplug event. So I guess you don't need to "store" hotplug event, because all the info is still available in sysfs. So the solution is something like :
run udev from initramfs
mount real root and switch root
scan sysfs (does udev do that on startup ?)
normal operation (ie wait for hotplug event)
Related
I have a task to make a virtual device under a real one with the help of device mapper kernel module. Virtual device must transfer any request to a real device, so both devices must be equal.
In prospective I should be able to control requests, so I wrote kernel module, representing device mapper target, using this article.
After making module and inserting it (insmod command) I setup my device (dmsetup create). Then do mount and can work with a real device through just created virtual.
But the question is how to repeat above mentioned instructions in boot time? I'd like to use my virtual device as a general one (by changing fstab, I guess).
Thanks in advance!
If you are going to use your device as the root filesystem, you need to create an initramfs that sets it up. Basically a shell script that issues dmsetup commands, followed by a mount and finally pivot_root to the new filesystem.
There was a discussion on the dm-devel mailing list last year on how to do this in the Linux kernel without an initramfs, by specifying mapper lines on the kernel command line. This is they way Chrome OS does it, because they can't/won't use an initramfs. See here for documentation of this feature. The functionality was never merged though.
The patch series was updated and resubmitted in May 2017. Hopefully we will eventually see it merged in some form or other.
If you are not going to use your device as the root filesystem, you can still use the same approach if you want, but there might be easier ways.
I am interested in writing my own tool in bash to act in place of my current network controller (wpa_supplicant) if possible. For example if I want to issue commands in order to begin a wps authentication session with a router's external registrar, is it possible, without using any pre-built tools, to communicate with the kernel to directly access the hardware? I have been told that I can achieve what I desire with a bash plugin called ctypes.sh but I am not too certain.
Generally speaking, the Linux kernel can interact with user-space through the following mechanisms:
Syscalls
Devices in /dev
Entries in /sys
Entries in /proc
Syscalls cannot be directly used from Bash but you need at least a binding through a C program.
You can create a Linux kernel driver or module which reads/writes data in an entry under /proc or /sys and then use a bash program to interact with it. Even if technically feasible, my personal opinion is that it is an overkill, and the usual C/C++ user-level programming with proper entries in /dev is much better.
No, this is generally not possible. Shell scripts can mess around in /proc, but they don't have the ability to perform arbitrary IOCTLs or even multi-step interactive IO. It's the wrong tool for the job.
I am writing a C program in Linux user space for an HMI. I want to detect the pendrive when inserted into the USB port on my SBC. I am running Lubuntu on it. So it is not having udev libraries. When I try to install udev on SBC, it is asking for dependencies and version compatibility issues are coming. Is there any other way to detect the Pendrive insertion from user space.
When I mount a device ex: /dev/sdc1(pendrive) to a particular folder ex: /mnt/vj, its being mounted properly. If I remove the pendrive without unmounting it then when next time pendrive inserted its being detected as /dev/sdd1 . How to fix the logical name for a pendrive in such cases. I want it to be /dev/sdc1 always. Is it possible?
Thanks in anticipation.
You can implement your own event listening daemon instead of udev. Youhave to create a netlink socket of type NETLINK_KOBJECT_UEVENT. By parsing the events, you will be able to detect the insertion of your drive.
It is not possible to ensure the name is always the same but you can probably create a symlink to the proper block device after detecting the event.
Check the link ubuntu 12.04 libudev-dev won't install because of dependencies that should mostly resolve your udev installation/dependencies issue if related to it.
udev is one of the easiest ways for detecting hardware plug-in and fetching of device information. Checkout libudev that is part of udev (Device manager of Linux kernel). Apart from managing device nodes in the /dev directory while hardware devices are added into the system or removed from it, the udev also handles all related user-space events that are raised during various operations such as addition/removal.
libudev allows access to device information and also provides a monitoring interface like udev_monitor that connects to device event source. udev_monitor_get_fd provides file descriptor that can be used with select system call for monitoring.
Check this link that has information related to usage of libudev http://www.signal11.us/oss/udev/
I want to write a program which notifies when the laptop battery level falls below a certain threshold level. I am using ubuntu 11.04 . Is there a way in which i can generate an interrupt without polling the battery. What system calls in linux are used to achieve this ?
There is no system call interface to ACPI in Linux... All of the I/O is done using /proc/acpi or /sys/class entries. Easiest implementation would be a polling software, and read the interface periodically (going to sleep if the threshold is not there yet) — this is because typically /proc and /sys files construct the desired information while handling the read(2).
What are the ways to communicate with a kernel module from user space? By communication i mean sending information and commands between the kernel module and a user space process.
I currently know of two way:
open/close/read/write/ioctl on published device node.
read/write on exported and hooked /proc file.
More specifically, can someone advice the best way to communicate with a kernel module that does not actually drives any hardware and therefore should not be littering /dev with stub nodes that exists solely for ioctl calls? I mostly need to check its various status variables and send it a block of data with a request type tag and see if the request succeeded.
Netlink sockets are designed for that kind of requirements, too...
Also see
man 7 netlink
libnl - Netlink library
The libnl Archives
There's also the /sys filesystem (sysfs):
Sysfs exports information about
devices and drivers from the kernel
device model to userspace, and is also
used for configuration.
(from Wikipedia)
You could also read/write from /dev device nodes.
IMHO, /dev is already littered with stuff and adding your own nodes there isn't a big issue. Don't forget that you can have lots of ioctl codes for a single device node, and the ioctl paramters are passed by reference so can be as big as you like.
Third one is add a new syscall, but the two you have written are the preferred ones, I think. I've found this document that might help, but I still think this option is unadvised: http://www.csee.umbc.edu/courses/undergraduate/CMSC421/fall02/burt/projects/howto_add_systemcall.html
Another acceptable option might be sharing memory.
You could also use Shared Memory and IOCTL
debugfs is another good possibility for APIs that are less stable than sysfs, but the API is basically the same. Here is a minimal runnable example.
configfs is another one. It allows easy dynamic creation of kernel objects from userspace through the filesystem: https://www.kernel.org/doc/Documentation/filesystems/configfs/configfs.txt
In any case, you will have to dirty some namespace... a filesystem entry in case of sysfs and debugfs. Just choose your poison.
Also, udev rules make /dev very similar to sysfs and debugfs: How to create a device in /dev automatically upon loading of the kernel module for a device driver?