5

Background

Hello.

I am trying to wrap my head around the relationship between a filesystem (ext2/3 etc), device drivers and device files.

I'll lay out my understanding of each term and then my questions.

Device Driver

As far as I understand, the device driver would be the kernel side code that handles the I/O and logic of accessing some device (mouse, flash memory, etc), and it needs to implement several functions (such as open, read, etc) and assigning them to some function pointers when registering the device.

Device File

The device file would be a file usually located in /dev which should be used as the interface to the device driver, through major and minor values assigned to that file.

Filesystem

I Don't think I fully understand this concept, a filesystem should handle I/O and general access to files stored physically on a drive, but that sounds like a device driver, so - would appreciate some more information here

Scenario

If, for example, I was to mount /dev/sdb1 which is my backup ssd to some mountpoint, say /mnt/temp - /dev/sdb1 would be the device file, and the filesystem type would be ext4. Now when I cd to /mnt/temp and use ls, the open method implemented by the device driver should be called.

My request/questions

  1. Is my understanding of device driver and file correct? If not I would appreciate some more details
  2. How does the appropriate open function gets called in the scenario I discussed?
  3. How exactly does the filesystem type plays any role in file access if the device driver is the one implementing the access?

Thank you for your help.

Yarden
  • 496
  • 1
  • 5
  • 16
  • 1
    Regarding filesystems, each filesystem type has a filesystem driver (i.e, the code that implements the logic of the filesystem). Some types of filesystems use block devices for storage - usually one main block device, but some filesystems can use extra block devices for special purposes. Other types of filesystem do not use block devices, for example virtual filesystems like procfs, and network filesystems like CIFS (at least as far as the client is concerned). – Ian Abbott Apr 08 '21 at 16:04
  • 4
    You need to be aware of layers, e.g. like a protocol stack. A filesystem implements a logical organization of blocks of data, which is at an upper layer (closer to userspace). A block device driver is at a lower layer (closer to the HW). A device driver in general simply provides access to a peripheral, ignores the data content, and transfers data in chunks supported by the device, e.g. sector or LBA, Ethernet frame, or individual bytes. IOW an **open()** syscall can use both filesystem & device driver functions – sawdust Apr 08 '21 at 21:14
  • The `open` system call will resolve the path and then get routed through the kernel's VFS (Virtual File System) layer to the appropriate filesystem driver to open the file. If the file is not a regular file or directory the call will get routed through to the appropriate handler for that type of file. For example, for "character device" files, it will be routed through to `chrdev_open` and then to the driver for that device if it has registered an 'open' file operation handler. – Ian Abbott Apr 09 '21 at 15:56
  • So if I understand you correctly, when accessing files on a mounted filesystem the operation is routed to the appropriate filesystem driver, unless I'm opening a special file (block/char devices) in which case the appropriate device driver functions would execute? – Yarden Apr 11 '21 at 12:23

1 Answers1

2

This is a good question, but pretty meaty! :)

Re your question 2., here's some info about what open is/does. open is a libc call - it's a C function that POSIX systems have to implement. Basically every distro nowadays uses a release of libc called glibc (the GNU libc implementation), but especially on embedded devices with limited RAM or storage resources, you still sometimes see folks using other libc implementations. Here's the manpage for glibc open. open works by trying to open files at a given pathname - it talks to the filesystem. To open, differences in the way the filesystem is implemented underlying storage layer don't matter. So, the phrasing of your question 2 as written right now ("How does the appropriate open function gets called in the scenario I discussed?") is a little bit off-base: there's only one open function, not multiple ones implemented per filesystem.

sinback
  • 926
  • 5
  • 17
  • Thank you for your answer! I'll try and clarify because I think I might be mixing some things. I understand that the glibc function wraps the actual syscall but i am still confused about the way a filesystem (which is supposed to manage data access to on disk files) "acts". From what I understood through the comments, when I try reading (glibc's `read`/`write`/`open` files on a mounted file system, there should be a filesystem driver in the kernel which gets these requests and handles it. I feel like there are a lot of gaps here, can you clarify it for me? – Yarden Apr 13 '21 at 07:10
  • I think I see what you're curious about more clearly. Yes, the kernel has a virtual filesystem (VFS) layer which is responsible for taking fs-related calls from userspace and dispatching the work that needs to be done on them to the filesystem driver that takes care of whatever filesystem the file being dealt with is on. The kernel's [documentation](https://www.kernel.org/doc/Documentation/filesystems/vfs.txt) on VFS is a good read on the details. Does that help? – sinback Apr 13 '21 at 13:17