What is the relationship between device drivers and a filesystem

Viewed 451

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.

1 Answers

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.

Related