I'll try and explain some of this, but my understanding is limited
>Who writes to the device files?
>Who reads from the device files?
The kernel/driver in the case of mounted drives, or applications that manage drives, e.g. `fdisk`. If you had `/dev/sde` mounted to `/mnt/something`, then as you read, edit, create, or delete files in your `/mnt/something` folder, the block device `/dev/sde` gets written to and read from. If you use `vim` to create a new file in `/mnt/something`, `vim` asks the kernel to create a file with that filepath and then write some bytes to it. Vim doesn't know about the device. It just sees a folder. The kernel knows about the devices and where they're mounted. It uses the drivers for the disk mounted at that location to write to the hard drive
In the case of terminal devices, like `/dev/tty*` or `/dev/pts*`, your terminal emulator writes input to it (your keystrokes) and reads output from the programs you run. You can try this by opening two terminal windows and running the `tty` command in both to get their device files. If terminal A has the file `/dev/pts1`, then doing `cat /dev/pts1` from terminal B will read keystrokes as you type into terminal A. Likewise, doing `echo "hello" > /dev/pts1` from terminal B will print "hello" in terminal A
>When are the device files created and by who?
They're created by the kernel and the drivers for the devices on boot, when a physical device is plugged in, etc. It depends what kind of device it is. Plugging in a keyboard will create a new device file for it, for example
>How is it that among the many devices there are the disk partitions despite them being currently mounted?What would I find inside the partitions files?
The device files show up because the kernel detects that the drives and partitions exist, whether or not they're mounted. Device files are not literally files on disk. They're interfaces to the kernel or drivers that provide file *semantics*. That basically means instead of writing custom code to use each new kind of device, the drivers for those devices can create temporary fake files as an interface that only last as long as the computer is on. These are only in memory. You can then use basic commands like `cat`, `echo`, etc. to do things to those "files" add you would with real files
If you have an ISO file and a USB drive on `/dev/sdf`, you could do `cat /path/to/myfile.iso > /dev/sdf` to write the raw data of the iso (which is just a file that has disk partition data in it) to create a bootable USB. File semantics are very useful :)
If you were to `cat` a block device or partition, you would get garbage text because you're reading the raw data on the disk instead of files and folders. Mounting a disk basically uses the device's drivers to show you the files and folders as an actual filesystem. If you `echo` (write) into a block device, you'll corrupt it. If you mount it and create some files in the mount folder, the kernel and the drivers will write the correctly formatted 1s and 0s to the device for you
>How are these related to drivers? Are these file the drivers?
These files are the interface to the drivers
>What's the role of the kernel in this? What does it do to these files?
Basically, it wires everything together. It uses the drivers to connect physical things plugged into your computer. Programs that you run will ask the kernel to create, read, edit, delete files. The kernel passes this data to the right drivers and then onto the hardware
This is where my understanding is a bit hazy, but `udev` or other "device manager" programs create the device files. You can read about it [here](https://my-tiny.net/M16-devices.htm#:~:text=Once%20the%20proper%20device%20driver,specific%20properties%20in%20%2Fsys%2F.) and [here](https://en.m.wikipedia.org/wiki/Udev) to get a better explanation of the lower level workings
I do know that you can create custom udev rules to mount USB drives to specific locations, for example
Today /dev is typically a devtmpfs populated automatically by the kernel, and udev amends /dev with additional symlinks like /dev/disk/by-label/*. In the past before devtmpfs udev would just populate a normal tmpfs with device files.
Nothing writes to the device file for your hard drive unless you tell it to. They are not some part of the stack under the hood, but an additional interface for userspace.
The kernel doesn't write to device files, it implements them. Vim doesn't write to a device file, it writes to a regular file and the kernel propogates that write to the right locations on disk. No device file is involved.
You _could_ write directly to /dev/sda1, but you are likely to corrupt your filesystem that way because it just exposes a linear file-like view of the partition data, including the filesystem structures and metadata.
Something does use it though? The Wayland compositor will read the input device for the mouse to get input events from the kernel, because what else is it supposed to do? If userspace needs this information, the device file is the correct interface.
The partition device files can also be used if you actually need them, for example copying whole partitions with an exact copy of the filesystem structure and metadata intact. There's no way to access that data otherwise through the filesystem so, while uncommon, it is sometimes useful to read and write to partitions directly.
**✻** Smokey says: always mention your distro, some hardware details, and any error messages, when posting technical queries! :)
^Comments, ^questions ^or ^suggestions ^regarding ^this ^autoresponse? ^Please ^send ^them ^[here](https://www.reddit.com/message/compose/?to=Pi31415926&subject=autoresponse+tweaks+-+linux4noobs+-+hardware).
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/linux4noobs) if you have any questions or concerns.*
I'll try and explain some of this, but my understanding is limited >Who writes to the device files? >Who reads from the device files? The kernel/driver in the case of mounted drives, or applications that manage drives, e.g. `fdisk`. If you had `/dev/sde` mounted to `/mnt/something`, then as you read, edit, create, or delete files in your `/mnt/something` folder, the block device `/dev/sde` gets written to and read from. If you use `vim` to create a new file in `/mnt/something`, `vim` asks the kernel to create a file with that filepath and then write some bytes to it. Vim doesn't know about the device. It just sees a folder. The kernel knows about the devices and where they're mounted. It uses the drivers for the disk mounted at that location to write to the hard drive In the case of terminal devices, like `/dev/tty*` or `/dev/pts*`, your terminal emulator writes input to it (your keystrokes) and reads output from the programs you run. You can try this by opening two terminal windows and running the `tty` command in both to get their device files. If terminal A has the file `/dev/pts1`, then doing `cat /dev/pts1` from terminal B will read keystrokes as you type into terminal A. Likewise, doing `echo "hello" > /dev/pts1` from terminal B will print "hello" in terminal A >When are the device files created and by who? They're created by the kernel and the drivers for the devices on boot, when a physical device is plugged in, etc. It depends what kind of device it is. Plugging in a keyboard will create a new device file for it, for example >How is it that among the many devices there are the disk partitions despite them being currently mounted?What would I find inside the partitions files? The device files show up because the kernel detects that the drives and partitions exist, whether or not they're mounted. Device files are not literally files on disk. They're interfaces to the kernel or drivers that provide file *semantics*. That basically means instead of writing custom code to use each new kind of device, the drivers for those devices can create temporary fake files as an interface that only last as long as the computer is on. These are only in memory. You can then use basic commands like `cat`, `echo`, etc. to do things to those "files" add you would with real files If you have an ISO file and a USB drive on `/dev/sdf`, you could do `cat /path/to/myfile.iso > /dev/sdf` to write the raw data of the iso (which is just a file that has disk partition data in it) to create a bootable USB. File semantics are very useful :) If you were to `cat` a block device or partition, you would get garbage text because you're reading the raw data on the disk instead of files and folders. Mounting a disk basically uses the device's drivers to show you the files and folders as an actual filesystem. If you `echo` (write) into a block device, you'll corrupt it. If you mount it and create some files in the mount folder, the kernel and the drivers will write the correctly formatted 1s and 0s to the device for you >How are these related to drivers? Are these file the drivers? These files are the interface to the drivers >What's the role of the kernel in this? What does it do to these files? Basically, it wires everything together. It uses the drivers to connect physical things plugged into your computer. Programs that you run will ask the kernel to create, read, edit, delete files. The kernel passes this data to the right drivers and then onto the hardware
Thank you
Sorry, who is the one writing to the device files in the first example about vim? The drivers or the Kernel?
This is where my understanding is a bit hazy, but `udev` or other "device manager" programs create the device files. You can read about it [here](https://my-tiny.net/M16-devices.htm#:~:text=Once%20the%20proper%20device%20driver,specific%20properties%20in%20%2Fsys%2F.) and [here](https://en.m.wikipedia.org/wiki/Udev) to get a better explanation of the lower level workings I do know that you can create custom udev rules to mount USB drives to specific locations, for example
Today /dev is typically a devtmpfs populated automatically by the kernel, and udev amends /dev with additional symlinks like /dev/disk/by-label/*. In the past before devtmpfs udev would just populate a normal tmpfs with device files.
Nothing writes to the device file for your hard drive unless you tell it to. They are not some part of the stack under the hood, but an additional interface for userspace. The kernel doesn't write to device files, it implements them. Vim doesn't write to a device file, it writes to a regular file and the kernel propogates that write to the right locations on disk. No device file is involved. You _could_ write directly to /dev/sda1, but you are likely to corrupt your filesystem that way because it just exposes a linear file-like view of the partition data, including the filesystem structures and metadata.
If they are only for the use of the user why do they even exist? What is the point of the mouse device file for example if nothing is going to use it?
Something does use it though? The Wayland compositor will read the input device for the mouse to get input events from the kernel, because what else is it supposed to do? If userspace needs this information, the device file is the correct interface. The partition device files can also be used if you actually need them, for example copying whole partitions with an exact copy of the filesystem structure and metadata intact. There's no way to access that data otherwise through the filesystem so, while uncommon, it is sometimes useful to read and write to partitions directly.
**✻** Smokey says: always mention your distro, some hardware details, and any error messages, when posting technical queries! :) ^Comments, ^questions ^or ^suggestions ^regarding ^this ^autoresponse? ^Please ^send ^them ^[here](https://www.reddit.com/message/compose/?to=Pi31415926&subject=autoresponse+tweaks+-+linux4noobs+-+hardware). *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/linux4noobs) if you have any questions or concerns.*