Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

How are devices, device drivers, device files and mounted points related in Linux (I am a beginning user of Ubuntu)?

My understanding about them is quite vague; I hope there will be some clear explanation to help me get the bigger picture.

share|improve this question
    
There's a similar question & answer here for those interested. –  boehj May 29 '11 at 4:06
add comment

4 Answers

up vote 5 down vote accepted

In the unix philosophy everything is in effect a text file file in the directory hierarchy, and everything here is really names for various 'files' in that hierarchy

A device is any physical hardware or virtual device (like dev/null) that can be used by the system = these are generally under /dev/.

For storage devices all partitions are under /dev/ and need to be mounted (/dev/sdx being the physical drive, and /dev/sdx1 /dev/sdx2.. being partitions) , using the appropriate device driver under some other location, typically /mnt/ or /media/ . You can however also mount a partition as a specific directory in the hierarchy, such as /home/ or even as a arbitrary directory, as long as you have permissions.A mountpoint is basically the location where a partition can be accessed, and its representation in the hierarchy

A device file is the representation of a device on the file system hierarchy

While this is usually abstracted away, when attaching a device, the necessary drivers are needed so that the system knows how to 'talk' to the physical device in question, and in the case of storage devices, the filessytems - a full mount command will include this, but usually its automatic. examples of this are the generic libata driver for hard drives, and ext3 or various fuse drivers for file systems.

share|improve this answer
    
Thanks! For a storage device, do its partitions and filesystems belong to the device or the device driver? –  Tim May 29 '11 at 6:01
    
er.. neither. each partition is a 'device' in its own right. The device driver merely ensures that the OS knows how to read it - same way that a physical PCIe is a 'device' and you need a driver for your computer to talk to it –  Journeyman Geek May 29 '11 at 10:36
add comment

device: typically a physical entity (i.e. a piece of hardware), but could also be just short for "device file" and an abstraction (e.g. mtd1 is the device name for a partition in flash memory, but is actually a driver layer that runs hierarchically on top of the actual flash memory device driver to make the flash device more block I/O friendly).

device driver: software that performs I/O operations on the device on behalf of the OS and/or user requests.

device file (or device node): the filename for user-accessible devices, usually in the directory /dev, with attributes for ownership and permissions. Note that some "devices" (e.g. Ethernet port eth0) do not have a user-accessible device file.

mounted point: a mount point is a directory in a filesystem (e.g. /mnt) that actually accesses another filesystem, usually on another device

share|improve this answer
add comment

In general:

  • Device = Hardware
  • Device driver = Interface between OS/program and hardware
  • Device file = Interface with the driver
  • Mounted point = Not as sure about this one, I think you are talking about "a physical location in the partition used as a root filesystem" (Wikipedia)
share|improve this answer
    
Thanks! "Device file = Interface with the driver", what interfaces with device deriver here? –  Tim May 29 '11 at 0:16
add comment

(The following is oversimplified but should give you a general idea)

The device is a piece of hardware either directly connected to the CPU (rare unless it's a bus) or indirectly connected via a bus (which is itself a device). Devices can communicate with the CPU using any of four methods: memory addresses, I/O addresses, DMA channels, and IRQs. (The age where you had to be concerned with those is long gone, it died with ISA).

One of the reasons we have operating systems is to provide a common interface to talk with types of hardware. So, those who write programs can use this common interface instead of being knowledgeable about the low level details of each specific device. This makes programming quicker and easier.

The driver is a piece of software that presents that common interface to the application side and then translates requests using that interface to a form the device can handle (using the aforementioned memory addresses, I/O addresses, DMA channels, and IRQs, or possibly calling other drivers), and back.

Linux, being a UNIX-style operating system, uses one particular "common interface" called the UNIX API. One design goal of UNIX is to make everything look like a file. The operations you can perform on files are: create, read, write, seek, and close. For things that don't fit neatly in these concepts, there is another operation called ioctl that's sort of a "catch-all" for everything else.

If you issue requests for these operations on a device file, the requests don't go to the filesystem layer of the kernel, but directly to the device.

Now, you have device files that let you talk to storage devices on a low level (/dev/sda, etc.), but storage devices are really stupid. All they can do through the UNIX API is give you a LBA, or block, of data (512, 2048, or 4096 bytes) or store it (modern hard drives have tens of millions of LBAs, if not more). They don't organize it into files by themselves. For example, writing to a file might involve writing to many LBAs, and you need a system to keep track of which LBAs belong to which file. This is the job of the filesystem layer of the kernel, translating requests for operations on files to requests for operations on devices and using part of that device storage to keep track of everything.

The filesystem layer is what implements the whole directory system. It's a tree structure, and you can attach, or mount block devices at various points in that tree. The filesystem layer needs to know what "low-level" device that has files, and that's why you need to mount it.

share|improve this answer
    
Thanks! I wonder if the filesystem on a storage device part of its device driver? Is the partition on it also part of its device driver? If not, what do they belong to, the device itself, or the OS? –  Tim May 29 '11 at 5:57
    
Filesystem modules and device drivers are separate. Usually a filesystem doesn't care about what underlying block device is "beneath" it, an exception being filesystems designed to work with raw flash memory. Good question about partition support; I wouldn't think it's part of the device driver but I've never tried doing crazy things like putting a partition table on floppies or CDs... cfdisk, a partition tool, doesn't display anything on my system but standard hard drives but I don't know offhand if that's something built into that tool or an OS/driver limitation. –  ultrasawblade May 29 '11 at 14:08
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.