I have written a Linux driver that is contained in a module. The probe() function sets up the hardware and creates a device file for userspace usage with device_create(). The device_create() is the last thing in the probe function.
I load the kernel module through the init_module syscall. It seems to me that the probe function is run as a callee of the syscall, i.e. that the probe function is done once the syscall returns to userspace. However I am not sure about this.
Sometimes, right after module insertion, the device file that is created through device_create is not there yet.
What is the correct way to wait for the driver has probed and all the effects of the probe such as created device files are visible?
A possible solution is waiting for node creation events in /dev by "inotify" API, provided that you can foresee the name. Here the official description and an example: https://man7.org/linux/man-pages/man7/inotify.7.html
Related
I browsed most of that litterature already and the kernel side of it is very much covered, understood and assimilated.
However my question is basically: How can I be alerted, for example through a callback function, when an interruption occurs in the kernel space and my daemon
lives in userspace.
IRQ Occuring -------> Upper half of the interrupt(put the timestamp in the buffer) ---------> Lower half of the interrupt handler (read data and adds the
timestamp in the buffer) -----------> ???? userspace daemon (async callback of some description) that will write a log on the HD.
I have everything up to the daemon part written and working, I seem to understand that through libiio you can assign a trigger to a particular channel or
attribute but that is where I get stuck.
Litterature on the libiio (most notably its wiki) has a chapter on triggers that is 4 lines long ... not very helpful to say the least.
iioinfo lists the devices present in the LSM6DSLTR (18 devices including two triggers) and I have been unable to assign the triggers to any device that they are
not assigned to already (No such file or directory) which I gather refer to the absence of the trigger directory in the sysfs for that particular device.
I also gather that the sysfs directory is, of course, slave to the kernel device tree and that the creation of that part of the device tree is made as the
driver is loaded.
So there must be a way to alter that part of the sysfs filesystem by asking the kernel driver to provision a device in the context to implement the trigger
directory so we can assign a trigger to it
second part will be to slave that trigger to an actual IRQ (42 in my case - as listed in /proc/interrupts) and be alerted in the userspace daemon when a
thresold has been reached in terms of either acceleration or vibration ...
Well, this is the nuts and bolts of what I am trying to achieve. the last part will be to write a few registers on the chip to configure how and when IRQ will
occur for any given integrated devices.
I'm writting a driver for a synthesized device in an FPGA. The device has several IRQs and have requested them on my driver:
irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
rc = request_irq(irq, &Custom_driver_handler,IRQF_TRIGGER_RISING , DRIVER_NAME, base_addr);
My problem is that i want that the irq_handler calls a function of an user space application. Is there any way to call my user space application from the irq_handler of the driver on kernel space??
I know i could save a flag from the driver and mmap its direction from the user application to polling it, but what i want to know is if there is any faster/more correct way.
Thank you in advance
There are several ways of invoking user-space functions from kernel, usually named upcalls: http://lkml.iu.edu/hypermail/linux/kernel/9809.3/0922.html; check also https://lwn.net/Articles/127698/ "Handling interrupts in user space" and the http://wiki.tldp.org/kernel_user_space_howto overview from 2008, part "Sending Signals from the Kernel to the User Space".
To make writing drivers easier, there is UIO framework in the kernel now: https://unix.stackexchange.com/questions/136274/can-i-achieve-functionality-similar-to-interrupts-in-linux-userspace https://lwn.net/Articles/232575/ https://yurovsky.github.io/2014/10/10/linux-uio-gpio-interrupt/ https://www.osadl.org/fileadmin/dam/rtlws/12/Koch.pdf http://www.hep.by/gnu/kernel/uio-howto/
With UIO you can block or poll special file descriptor to wait for interrupt (block by using read() syscall; poll with poll syscall): https://lwn.net/Articles/232575/
On the user space side, the first UIO-handled device will show up as /dev/uio0 (assuming a normal udev setup). The user-space driver will open the device. Reading the device returns an int value which is the event count (number of interrupts) seen by the device; if no interrupts have come in since the last read, the operation will block until an interrupt happens (though non-blocking operation is supported in the usual way as well). The file descriptor can be passed to poll().
include/linux/uio_driver.h is available in linux kernel for many years, it is here for 3. and 4. versions of kernel.
currently i write an driver module which offers some entries in the sysfs. I read a lot through the driver source tree and the internet. I found two approches where the sysfs_create_group() is called:
a) most commonly: In the probe() function of the Driver. Like adviced here
How to attach file operations to sysfs attribute in platform driver?
Random Thing i looked at:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/rtc/rtc-ds1307.c#n1580
b) In the driver struct.
http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/
I know, Greg KH is a very well known developer. So i tried to follow his advice. In the bla_show()/bla_store() functions i tried to get my Driver private data, but my printk()'s showed much different addresses than i printed in the probe() function. My private data is (null). Which is ofc wrong.
When i use approch a) it works as expected, but as Greg KH suggests it is wrong too. I see it a lot in the stable tree in different drivers. Greg writes, the userspace already got the notification that there is a new device, but the LDD3 book states, that the probe function is there to determine if the device is present.
To sum my question up:
Why get the userspace notified about it, even when the kernel doesnt know if it can handle it?
Where is the right place to call sysfs_create_group()? Is it a) or b) ?
LDD3: https://static.lwn.net/images/pdf/LDD3/ch14.pdf
PDF page 24
probe is a function called to query the existence of a specific device
(and whether this driver can work with it), remove is called when the
device is removed from the system,and shutdown is called at shutdown
time to quiesce the device.
I am more confused than before .....
Best Regards
Georg
A device driver is a program that controls a particular type of device that is attached to your computer.
Platform devices are inherently not discoverable, i.e. the hardware cannot say "Hey! I'm present!" to the software. So for these kind of device we need a driver which call as Platform drivers. Drivers provide probe() and remove() methods.
struct platform_driver {
int (*probe)(struct platform_device *);
int (*remove)(struct platform_device *);
.
.
struct device_driver driver;// this file has 2 parameter name or owner.
};
probe() should in general verify that the specified device hardware
actually exists. First we register our driver. Once it found device then it'll call driver probe. It is using name for searching a device.
Ans : your device is available then you need sysfs entry for communication (To the user space). so conceptually you need to define you sysfs entry in probe.
sys_notify function on your attribute and it will cause your userspace code to wake up. It will trigger when sysfs is available for userspace. It just avoiding a blocking call. When kernel does not have sysfs then it'll not notify userspace.
sysfs is a virtual file system provided by the Linux kernel that exports information about various kernel subsystems, hardware devices, and associated device drivers from the kernel's device model to user space through virtual files. When your device is available then you need this entry to export your information.
I'm new in developing Linux driver.
Traditionally, If i want to create char device, I just need to implement read write and ioctl functions, and register it by register_chrdev_region with corresponding Major device ID. And then use mknod to create a device file of that Major device ID. Then call read write open in user space will then call the corresponding functions by kernel.
But now i'm studying Linux device model and sys filesystem, which is added in kernel 2.6. I'm told if possible, Don't use /dev filesystem, as linux now has a good device model to handle device and driver.This confused me, so I'll summarize my confusion into some questions:
How do I create a char device in /sys? To be more specific, how do I create a null device just like /dev/null?
How do I call my char device driver function from userspace?
I heard that udev is based on sys filesystem to create device file in /dev. Why? Since I'm told "If possible, Don't use /dev filesystem", why does udev use /sys to create file in /dev?
Does a file in sys have any conceptions like char device file or block device?
In /dev, open write from user space will finally map to functions in file operation structure defined by me, then what functions will be called when I open or write to files in /ssy?
Without context your statement about /dev is not clear. Anyway:
You cannot create char devices on sysfs. The main purpose of sysfs is to export information and allow the user to adjust single values (just navigate under /sys/ for some examples). Char devices usually does much complicated things.
If you mean how you call your driver's open,read,write,ioctl, ... well, by doing open(2), read(2), write(2), ioctl(2) (look at man pages of these commands)
when a device appear, the kernel create a directory under /sys. For example take a look at ls /sys/bus/usb/devices/. All that directories are created when an USB device appear. You can try by plug/unplug USB devices. udev put an eye on sysfs to detect new devices and according to the information from sysfs it create the device under /dev. This happens when the driver, somehow, calls device_add(). Often this functions is invoked by other register functions like: device_create, device_register, or other from other sub-systems.
the idea of sysfs is to provide information about the devices and drivers loaded. So you can change device, bus and driver options. Or manually attach a device to a module
Actually, behind the sysfs attributes there is a set of file_operation, where open, read and write are managed by the kernel and not by your driver. In order to create a sysfs attribute you have to provide the pair of function show and store to read/write something from/to the driver. Then the kernel will route the requests to your correct attribute
I am just starting to look at the I2C support on (embedded) linux (Beaglebone Black, to be precise). Since it's linux, everything is a file, so it's no surprise that I2C is too.
int file = open( "/dev/i2c-0", O_RDWR );
and then the actual address on that bus is selected through ioctl(). My question is this - is it safe, or even legal, to cache file for the duration of application execution? It would seem to my naive eyes that the overheading of opening a resource to read every 250ms would be an unnecessary strain on the kernel. So it is valid to open, and then just use ioctl() to switch address whenever I need to, or must I close() the descriptor between reads and writes?
is it safe, or even legal, to cache file for the duration of application execution?
The file descriptor (that is returned from open()) is valid for as long as your program needs to keep executing.
Device nodes in /dev may resemble filenames, but they are treated differently from filesystem entries once you look past the syscall interface. An open() or read() on a file descriptor for a device will invoke the device driver, whereas for an actual file its filesystem is invoked, which may eventually call a storage device driver.
It would seem to my naive eyes that the overheading of opening a resource to read every 250ms would be an unnecessary strain on the kernel.
Yes it would since those open() and close() syscalls are unnecessary.
So it is valid to open, and then just use ioctl() to switch address whenever I need to,
Yes, that is the proper useage.
or must I close() the descriptor between reads and writes?
That is not necessary nor advised.