I have a serial device that shows output at /dev/ttyX. I can cat this and watch the output come in on my current terminal, But I want to log the output to the system journal even if I'm not at a terminal. I could make a systemd service that is basically (pseudocode) tail -f /dev/ttyX | systemd-cat -t mydevice -p info. But is there a more built-in way to tell systemd to put the contents in the journal?

This was originally asked on [Stack Overflow](https://stackoverflow.com/questions/79329706/udev-rule-for-syfs-class-device-attributes) , but it was closed for being off-topic. Hopefully this is the right forum for the question. I'm writing a character device driver that exposes class and device attributes under sysfs. I'm using udev to make the devices that appear in /dev read/writable by a certain group, but I can't figure out how to make the sysfs attributes writable by the same group without a shell script.

$ ls -l /dev/foobar
crw-rw---- 1 root my_group 241, 0 Jan  4 21:57 /dev/foobar # ownership applied by udev
$ ls -l /sys/class/my_class/wo_attribute
--w--w---- 1 root root 4096 Jan  4 22:02 wo_attribute # still in root group :/
$ ls -l /sys/class/my_class/my_device/rw_attribute
-rw-rw-r-- 1 root root 4096 Jan  4 22:13 rw_attribute # ditto

I've tried using udevadm info to match the KERNEL and SUBSYSTEM keys of the sysfs path to no effect. I've also found the udev_event and get_ownership fields of struct class; I haven't had luck with the former and the latter works for device attributes, but I have to hard code my_group's gid which is not ideal. Here's an example of trying to find the right match keys for the class:

$ udevadm info -a /sys/class/my_module
 looking at device '/class/my_class':
    KERNEL=="my_class"
    SUBSYSTEM=="subsystem"
    DRIVER==""
    ATTR{wo_attribute}=="(not readable)"

  looking at parent device '/class':
    KERNELS=="class"
    SUBSYSTEMS==""
    DRIVERS==""
    ATTRS{devcoredump/disabled}=="0"
    ATTRS{drm/version}=="drm 1.1.0 20060810"
    ATTRS{firmware/timeout}=="60"
    ATTRS{gpio/export}=="(not readable)"
    ATTRS{gpio/unexport}=="(not readable)"
    ATTRS{my_class/wo_attribute}=="(not readable)"

But the udev rule KERNEL=="my_class", GROUP="my_group" doesn't work. Does udev only work with devices under /dev, or is there a way to apply the rules to sysfs attributes?

Linux Device Drivers, 3rd Edition states: > if the llseek method is missing from the device's operations, the > default implementation in the kernel performs seeks by modifying > filp->f_pos Yet I have a character device for which driver doesn't implement lseek. Here are file op definitions for this device type: https://github.com/Xilinx/dma_ip_drivers/blob/master/XDMA/linux-kernel/xdma/cdev_ctrl.c But attempting lseek on this device returns ESPIPE:

-c
#include 
#include 
#include 
#include 
#include 
#include 
int main(int argc, char** argv) {
    uint32_t val=0x12345678;
    int fid=open("/dev/xdma0_user", O_RDWR);
    off_t lseek_ret=lseek(fid, 0x8ul, SEEK_SET);
    if (lseek_ret <0)
        fprintf(stderr, "Seek result: %d, errno: %s (%d)\n", lseek_ret, strerror(errno), errno );
    unsigned int c=write(fid, &val, sizeof(val));
    printf("written %u bytes\n", c);
    close(fid);
    return (0);
}

Output: Seek result: -1, errno: Illegal seek (29) written 4 bytes I can't understand how this comes about. It can't stem from the driver: ESPIPE isn't even mentioned anywhere in it, so it must come from the kernel, which contradicts the quote above. Has the default behaviour been altered? Can it be somehow configured? How can be seen what kernel actually does (ideally source code)? Kernel version is 5.10 (Debian 11).

### tl;dr If I want my module do adhere to modern practices, should I create devices in /dev/ via mknod in a shell script or via class_create and device_create C functions directly in the module source code? What are the advantages of one approach over the other? ### In detail In [Chapter 3](https://www.oreilly.com/catalog/linuxdrive3/book/ch03.pdf) of [_Linux Device Drivers, Third Edition_](https://www.oreilly.com/openbook/linuxdrive3/book/) , page 45 the function register_chrdev_region is presented as the function to use for registering a character device if the device numbers are known. However, since device numbers unused today could become used by the kernel tomorrow, the usage of this function is discouraged almost immediately, at page 46, in favor of alloc_chrdev_region, which allows a dynamic allocation of major numbers. At this point, though, the authors make the point that one can't create device nodes in /dev/ in advance because to create them the major number has to be known, and it isn't known before alloc_chrdev_region returns. The presented solution is a shell script, which: - loads the module with insmod, - which calls the module's init function, - which calls alloc_chrdev_region, - which results in a new device in /proc/devices, - uses awk to extract the major number from that device, - finally passes that major number to mknod to create device files in /dev/ (the minor number is encoded in the name of the device files). However, [_The Linux Kernel Module Programming Guide_](https://sysprog21.github.io/lkmpg/) makes use of functions class_create and device_create, **I believe** to accomplish the same task. What makes me nervous about it is that, despite the book [being still updated nowawdays](https://github.com/sysprog21/lkmpg/commits/master) , it has some aspect that makes it older than _Linux Device Drivers, Third Edition_. For instance, it makes use of register_chrdev, even though it suggests preferring register_chrdev_region or alloc_chrdev_region, whereas _Linux Device Drivers, Third Edition_ is more categorical in calling register_chrdev **The Older Way**, relegating its explanation to barely more than half of page 57. On the other hand, _The Linux Kernel Module Programming Guide_ is not the only source that I've found that uses class_create and device_create C functions, rather than mknod shell function, to create device files. [Here](https://olegkutkov.me/2018/03/14/simple-linux-character-device-driver/) 's another one, blog post written in early 2018. So how are things meant to be done today?

A character device file is a special linux file where you can read from and write to an infinite number of chars and other file operations that you can define inside a kernel device driver.
But does this file actually exist? If we look at it as normal text file is it possible to read the contents that are inside? Like major, minor numbers? Something similar we have with soft links. On linux machine the link is actually a path in system, but after committing it to git for example we see only "normal" text file with one string, a path to source directory.

Taking inspiration from [this blog post](https://olegkutkov.me/2018/03/14/simple-linux-character-device-driver/) , I'm playing around with linux device drivers (which I'm studying from []()). The read field of the file_operations associated with the driver is initialized to the function below:

static ssize_t mychardev_read(struct file *file, char __user *buf, size_t count, loff_t *offset)
{
    uint8_t *data = "Hello from the kernel world!\n";
    size_t datalen = strlen(data);

    printk("MYCHARDEV: mychardev_read was called with count equal to %zu\n", count);

    if (count > datalen) {
        count = datalen;
    }

    if (copy_to_user(buf, data, count)) {
        return -EFAULT;
    }

    return count;
}

My understanding is that, when the user space requests a given amount of data from the device created by this driver, the transfer happens in batches of at most the datalen, i.e. the length of the data string, which in this case is 29 (including the trailing \n). This is confirmed by the fact that executing the following commands in the shell

$ head -c 5 /dev/mychardev-0
$ head -c 29 /dev/mychardev-0
$ head -c 30 /dev/mychardev-0
$ head -c 32 /dev/mychardev-0

results in these lines in the output of dmesg (assuming I have obvious printk calls in the open and release methods):

[10782.052736] MYCHARDEV: Device open
[10782.052743] MYCHARDEV: mychardev_read was called with count equal to 5
[10782.052751] MYCHARDEV: Device close
[10868.275577] MYCHARDEV: Device open
[10868.275585] MYCHARDEV: mychardev_read was called with count equal to 29
[10868.275598] MYCHARDEV: Device close
[10878.414433] MYCHARDEV: Device open
[10830.796424] MYCHARDEV: mychardev_read was called with count equal to 30
[10830.796438] MYCHARDEV: mychardev_read was called with count equal to 1
[10830.796443] MYCHARDEV: Device close
[10830.796417] MYCHARDEV: Device open
[10878.414441] MYCHARDEV: mychardev_read was called with count equal to 32
[10878.414455] MYCHARDEV: mychardev_read was called with count equal to 3
[10878.414460] MYCHARDEV: Device close

What I don't understand is why the following command

$ cat /dev/mychardev-0 | head -c 5

results in

[11186.036107] MYCHARDEV: Device open
[11186.036120] MYCHARDEV: mychardev_read was called with count equal to 8192
[11186.036131] MYCHARDEV: mychardev_read was called with count equal to 8192
[11186.036136] MYCHARDEV: mychardev_read was called with count equal to 8192
[11186.036141] MYCHARDEV: mychardev_read was called with count equal to 8192
[11186.036145] MYCHARDEV: mychardev_read was called with count equal to 8192
[11186.036150] MYCHARDEV: mychardev_read was called with count equal to 8192
[11186.036154] MYCHARDEV: mychardev_read was called with count equal to 8192
[11186.036159] MYCHARDEV: mychardev_read was called with count equal to 8192
[11186.036163] MYCHARDEV: mychardev_read was called with count equal to 8192
[11186.036168] MYCHARDEV: mychardev_read was called with count equal to 8192
[11186.036172] MYCHARDEV: mychardev_read was called with count equal to 8192
[11186.036177] MYCHARDEV: mychardev_read was called with count equal to 8192
[11186.036181] MYCHARDEV: mychardev_read was called with count equal to 8192
[11186.036187] MYCHARDEV: Device close

In principle, I understand that maybe cat is requesting (or should I say the shell runtime on behalf of cat? Or what?) data from the driver in batches of several bytes at a time (in this case 8192, apparently), rather byte-by-byte, for the sake of being more performant. But I don't understand why is it called so many times?

I have to write a device driver code for temperature sensor using IOCTL, when I was going through a lot of sample codes, I found while surfing the net, I came across this difference in header file, I counldn't get an accurate answer for it, hence I'm posting it here, hoping that I may get a lead to work with my code.

I am currently studying device drivers in an operating systems course and am getting confused regarding the difference between the "inode" structs and "cdev" structs. Could someone clarify the differences between these two structures and what they're meant to achieve?

**Context:** Consider the following set of operations {A, B, C, D, E}: * (A) : On the read() function of my device driver, I add the calling thread to a wait queue wq if a driver's buffer buf is empty. More specifically, the calling thread is added to the queue via: wait_event_interruptible(wq, strlen(buf) > 0) * (B) : Similarly, on the ioctl() function of the driver, I add the calling thread to the same queue wq if the passed ioctl command is MY_IOCTL_X and if a driver's flag is_free == 0. Again, the calling thread is added to the waiting queue via: wait_event_interruptible(wq, is_free != 0) * (C) : On the driver's write() function, I pass the user-space content to buff, and call wake_up_interruptible(&wq), so that to wake up the thread put to 'sleep' in read(). * (D) : On the driver's ioctl() function, if the ioctl command is MY_IOCTL_Y, I set is_free = 1, and call wake_up_interruptible(&wq), in order to wake up the thread put to 'sleep' by ioctl(MY_IOCTL_X). * (E) : I've created a print_wait_queue() function to print the PIDs of the threads in the waiting queue. I call it before **and after** calling wake_up_interruptible() in operations C and D. The print function is implemented like this: void print_wait_queue(struct wait_queue_head* wq) { struct list_head *i, *tmp; pr_info("waiting queue: ["); list_for_each_safe(i, tmp, &(wq->head)) { struct wait_queue_entry* wq_item = list_entry(i, struct wait_queue_entry, entry); struct task_struct* task = (struct task_struct*) wq_item->private; pr_info("%d,", task->pid); } pr_info("]\n"); } **Problem:** The actual queueing and de-queueing seems to be working as intended, no issues here. However, the printing of the wait queue is not. Let's say I perform the operations described above, in this order: A -> B -> C -> D. This is what I get in the console (simplified output): 1. “waiting queue : [pid_1, pid_2]” // before calling wake_up_interruptible() on write() 2. “waiting queue : []” // after calling wake_up_interruptible() on write() (**I was expecting [pid_2]**) 3. “waiting queue : [pid_2]” // before calling wake_up_interruptible() on ioctl(MY_IOCTL_Y) 4. “waiting queue : []” // after calling wake_up_interruptible() on ioctl(MY_IOCTL_Y) As shown above, at print #2, the PID of the remaining thread - pid_2 - doesn’t show up in the PID list. Instead, I get an empty list. However, pid_2 shows up in the list before calling wake_up_interruptible() on ioctl(MY_IOCTL_Y) at print #3, as expected, indicating that pid_2 is actually kept in the waiting queue in-between prints #2 and #3. **Questions:** Why don’t I get [pid_2] at print #2 above, but then get it at #3? I’ve tried protecting the wait queue cycle in print_wait_queue() with a lock and it didn’t solve the printing issue. I've also confirmed that the address that the pointer I pass to print_wait_queue() always points to the same address.

This video shows an example Raspberry Pi Linux kernel module which creates a new character device. It uses the kernel API register_chdev. In a comment to the video (I can not generate a direct link to it), as regards the return value of register_chdev, the author states: > If the return value is not equal to 0, the device number is already in use. The upper 12 bits of the return value are your major device number, the lower 20 bits are the minor device number. I guess that by "the device number is already in use" he means "the non-zero major device number arbitrarily chosen in the kernel module is already in use". Despite several webpages deal with this (the official one , then this one and this one ), I did not find any information about this internal subdivision of the return value. If I choose to create (with my kernel module) a device with a major number already in use, the kernel does never accept it and refuses to register the device. This occurs both when the major number I chose is the same as the one of a block device, and when the major number I choose is the same as the one of a character device. register_chdev always return a negative value. In the latter case, instead, I was expecting a positive non-zero return value, with the upper 12 bits representing the major device number, and the lower 20 bits representing the minor device number (maybe greater than 0: if the major number was already used, maybe the system already had at least a device related to it, with the minor number 0). Is it true what is stated in the Youtube comment? Where can I find some documentation about it? ---------- I'm running Raspbian 10, uname -a shows: Linux raspberrypi 5.10.63-v7+ #1459 SMP Wed Oct 6 16:41:10 BST 2021 armv7l GNU/Linux

On UNIX OS, for which of the following I/O devices the access is not via a special file of type "character I/O"? 1. Mouse 2. Screen 3. Disk On Key (USB) 4. Printer 5. None of the above This question is from a test on Operation System course. I chose answer number 5 but my teacher says that the only correct answer is answer number 3. Is there a special case where answer number 3 on USB falls? I would be happy for an edge case so they can accept my appeal please and I will not fail. Thanks in advance.

I'm working with USB and I want to read the content of usb device descriptor in /dev/bus/usb/00x/00y - it is a character device. I used fopen to open it as a binary file with "rb" parameter. But when I do the seek and tell to get file size, it returned 0 bytes in size. Is there a way to read it as a binary file?

void ReadUsbDeviceDescriptor( const char* path )
{
    FILE* usb_fd = NULL;
    size_t lSize = 0;

    if ( path != NULL )
    {
        usb_fd = fopen ( path, "rb");
        if ( usb_fd != NULL )
        {
            fseek( usb_fd , 0 , SEEK_END );
            lSize = ftell (usb_fd);
            rewind( usb_fd );

            printf("File: %s - Size: %lu bytes\n", path, lSize);

            fclose( usb_fd );
        }
        else
        {
            printf("Could not open file %s\n", path );
        }
    }
}

And here is the result:

File: /dev/bus/usb/001/001 - Size: 0 bytes

I am wondering what happens when two processes write to a character device file at the same time. Currently, I am mostly worried about /dev/spidev0.0 on a Raspberry pi. If I assume correctly that it's the drivers task to deal with concurrent writes, does the driver see which processes have written which data? Or does the driver only see only continous data stream where all the concurrent writes get mixed in?

I have a character devices file , say /dev/X and I would like to capture every interaction which goes in and out of /dev/X. I'm looking for a way to create some kind of MITM/Proxy to that file. **Edit:** Regarding what X is, it is FM interface over android. So /dev/fm is the character device file. The end goal is to intercept any command that is sent to this file.

Let's consider the following (imaginary) device: a clock which takes 1 second to query, then returns the current time. We want to write a character device driver for it, which supports read operations only. - I believe non-blocking reads would not make sense for such a device, because we cannot cache the results of a read. Would you agree? - Is it allowed to only handle blocking reads? If so, what error code should non-blocking reads return? Or what other way do we have to specify that we don't support non-blocking operations? I'd like to understand this better before I implement a character device driver for a real device. I'm interested in Linux, but I believe the answer is unlikely to be Linux-specific.

I need to write a new character device file for the UART, which allows a few more file operations than usually allowed (not just open, write, etc..) I'm on an embedded mainline linux kernel (v 5.4). I started looking at the UART drivers and notice there are many things: 1. First, there are a lot of tty files. I know that tty stands for Teletypewriter. I don't think it's a piece of hardware. 2. Then, there is the specific driver for my processor, which handles interrupts on UART. 3. Then, there is (what I believe to be) the character device driver for uart, written in serial_core.c I remarked that serial_core.c doesn't have a file operations struct, but uses a tty_operations. What is happening here? I cannot understand how all these files are related to each other, what do they really do. More precisely, I would like to understand the role of each one of them. I'm tasked to write a character device driver for the uart but I do not know which one of these files (maybe all?) would my driver have to substitute. Thanks,

I write a program which should handle a motion sensor and an ultrasonic sensor at the same time. I'm using a Jetson Nano with 40 GPIO-pins. The first one uses I2C interface and thus accesses /dev/i2c-1 with the linux-intern libi2c-library while the other uses /dev/mem to write hex values directly to the pins. Now when I run them separately, they work just fine, but when trying to combine them in one single code file, they crash. The I2C-sensor just gives an unknown error and freezes. I wanted to ask whether it is possible that they collide when used simultaneously and you have any suggestion how to avoid this? Is there a way to run an I2C-sensor and an ultrasonic sensor in parallel? Thanks for the answers in advance!

I am learning device drivers and I got this doubt , is keyboard driver a character device driver in Linux?

I am trying to write a kernel module which loads upon detection of USB Mouse. I am new to this stuff, I googled for this issue but couldn't find any appropriate solution. can anyone please explain flow of this?

I created the device file under /dev folder successfully, but writing to that device file makes kernel to throw following error messages. Message from syslogd@beaglebone at Feb 26 15:40:10 ... kernel:[10090.943733] Internal error: : 1b [#3] PREEMPT SMP ARM Message from syslogd@beaglebone at Feb 26 15:40:10 ... kernel:[10091.049020] Process echo (pid: 3728, stack limit = 0xdc40a218) Message from syslogd@beaglebone at Feb 26 15:40:10 ... kernel:[10091.054880] Stack: (0xdc40be60 to 0xdc40c000) Message from syslogd@beaglebone at Feb 26 15:40:10 ... kernel:[10091.059267] be60: c15491c6 00000022 dc5cb14c bf30430c dc40bedc dc40be88 c075312c c074fe5c Message from syslogd@beaglebone at Feb 26 15:40:10 ... kernel:[10091.067488] be80: c0753018 ffffff04 ffff0a00 c140414c c0d407c8 bf30430c c140414c 40cfbcf3 Message from syslogd@beaglebone at Feb 26 15:40:10 ... kernel:[10091.075709] bea0: 00852878 ffffff04 ffff0a00 00040952 c01a7404 c140414c 00852878 00852878 Segmentation fault I know very basic of Linux Device Drivers Can anyone help me with this issue?? I am attaching the code snippet I'm using for character file writing #include #include #include #include #include #include MODULE_AUTHOR("RUCHA"); MODULE_DESCRIPTION("Character Driver First test"); MODULE_LICENSE("GPL"); MODULE_VERSION("0.0.1"); static int MajorNum; static struct class* RetValOfClassRegistration = NULL; static struct device* RetVal = NULL; static char message; static int openDev(struct inode * , struct file *); static int closeDev(struct inode * , struct file *); static ssize_t readDev(struct file *, char *, size_t, loff_t *); static ssize_t writeDev(struct file *, const char *, size_t, loff_t *); static struct file_operations FileOps = { .owner = THIS_MODULE, .open = openDev, .read = readDev, .write = writeDev, .release = closeDev, }; static int registerCharDev(void){ return register_chrdev(0,"MyDev",&FileOps); } static int __init Loaded(void){ // registering device MajorNum = registerCharDev(); if(MajorNum /dev/MyDev please help me regarding this!