In the idea of providing real content, I think I'll expand on a response to recent email thread that tried to explain how a module can be automatically loaded if a userspace program tries to access a /dev node.

The original question is here if people are interested.

---

So, how does this all work. I'll be talking about the 2.6.8 kernel tree here, but the basic idea should remain the same for all older (and possibly newer) kernels.

First off, a userspace program tries to open a file in /dev. /dev traditionally holds all device nodes for the system. A device node is the file that a userspace program can open, and then read and write to, in order to communicate with a specific piece of hardware attached to the system, or any other type of logical device that the kernel allows userspace to access.
Examples of physical devices are:

• /dev/ttyS0 for the first serial port on a machine.
• /dev/hda for the first IDE block device on a machine.
• /dev/sound/dsb for the first sound device on a machine.

Notice that I mention "first" device. That can get really messy for devices with more than one type of the same device, and the ordering of how the kernel probes the devices in the same order all the time is one reason that I created udev.

Examples of logical devices are:

• /dev/input/mice is the sum of all mice connected to the machine.
• /dev/null is a place to copy files to that will never be found again.
• /dev/zero is a place to copy data from that is always zero.
• /dev/random is a place to read random data from.

So, a userspace program makes a open syscall on a file in the /dev directory. That thunks into the kernel, and calls the function sys_open which is located in the file fs/open.c in the kernel tree. That function does:

• some housekeeping
• looks up the full path to the file passed to it
• mucks around in the vfs to get the inode associated with the specific file passed to it

Now that the inode for the file is found, oh wait, whats a inode? An inode in this instance, is the internal kernel structure that corrisponds with a specific file. It holds all kinds of general information about the file, including, which is important in this example, a pointer to the functions that should be called if this inode is really a block or character device, and not a "real" file.

So, within this inode, is a pointer to the open function for a character device (let's use a character device for our example, it's easier that way). That pointer points to the function chrdev_open, which is located in the file fs/char_dev.c, and the function is then called.

To be continued...

posted Mon, 04 Oct 2004 in [/linux]