Understanding /dev and its subdirs and files Announcing the arrival of Valued Associate #679:...

Problem with display of presentation

Why are current probes so expensive?

Noise in Eigenvalues plot

Is there a spell that can create a permanent fire?

Where and when has Thucydides been studied?

Can gravitational waves pass through a black hole?

How to make an animal which can only breed for a certain number of generations?

How can I list files in reverse time order by a command and pass them as arguments to another command?

Diophantine equation 3^a+1=3^b+5^c

Why are two-digit numbers in Jonathan Swift's "Gulliver's Travels" (1726) written in "German style"?

An isoperimetric-type inequality inside a cube

Any stored/leased 737s that could substitute for grounded MAXs?

Derived column in a data extension

Is this Half dragon Quaggoth Balanced

How does TikZ render an arc?

French equivalents of おしゃれは足元から (Every good outfit starts with the shoes)

Where did Ptolemy compare the Earth to the distance of fixed stars?

Does the main washing effect of soap come from foam?

Why complex landing gears are used instead of simple, reliable and light weight muscle wire or shape memory alloys?

Is this Kuo-toa homebrew race balanced?

Why does BitLocker not use RSA?

What is the proper term for etching or digging of wall to hide conduit of cables

Russian equivalents of おしゃれは足元から (Every good outfit starts with the shoes)

My mentor says to set image to Fine instead of RAW — how is this different from JPG?



Understanding /dev and its subdirs and files



Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern)
2019 Community Moderator Election Results
Why I closed the “Why is Kali so hard” questionWhy does the UNIX system need so many [0-byte] drives at /dev/*ls -l output in /dev directory of Unix/Linux systemWhat is the '/dev/stdin'?What are character special and block special files in a unix system?What do the device files in /dev actually do?How does /dev/fd relate to /proc/self/fd/?Difference between Device file and device driversWhat and Why? - File DescriptorsHow to inspect the contents of /dev/sdtCat won't access file in openSuse Tumbleweed ('Invalid argument' error)How to troubleshoot udev not creating /dev/hda3 on gentoo boot?renaming a directory and its subdirs without affecting their filesUnderstanding getlogin spoofingIs tty_nr referenced anywhere else in GNU/Linux procfs?Difference between /dev/null and /dev/zeroDo the standard streams all operate on the same file (/dev/tty)?Why does tcsh consistently have multiple fd's pointing to /dev/ttyDevice Node not createdIs it possible to use a pseudoterminal to redirect PPP’s dataflow to an application?What is `/dev/console` used for?





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







47















$ ls -l /dev/stdin /dev/fd/0
lrwx------ 1 tim tim 64 2011-08-07 09:53 /dev/fd/0 -> /dev/pts/2
lrwxrwxrwx 1 root root 15 2011-08-06 08:14 /dev/stdin -> /proc/self/fd/0
$ ls -l /dev/pts/2 /proc/self/fd/0
crw--w---- 1 tim tty 136, 2 2011-08-07 09:54 /dev/pts/2
lrwx------ 1 tim tim 64 2011-08-07 09:54 /proc/self/fd/0 -> /dev/pts/2



  1. I was wondering if all the files under /dev and its subdirectories
    are all file descriptors of devices?

  2. Why are there so many links from each other? For example, /dev/fd/0,
    /dev/stdin, /proc/self/fd/0 are all links to /dev/pts/2.

  3. If l in lrwx------ mean link, what does c in crw--w----
    mean?










share|improve this question




















  • 2





    And to answer #3, the c stands for character device, or character special. b stands for block special.

    – felixphew
    Dec 29 '14 at 19:48


















47















$ ls -l /dev/stdin /dev/fd/0
lrwx------ 1 tim tim 64 2011-08-07 09:53 /dev/fd/0 -> /dev/pts/2
lrwxrwxrwx 1 root root 15 2011-08-06 08:14 /dev/stdin -> /proc/self/fd/0
$ ls -l /dev/pts/2 /proc/self/fd/0
crw--w---- 1 tim tty 136, 2 2011-08-07 09:54 /dev/pts/2
lrwx------ 1 tim tim 64 2011-08-07 09:54 /proc/self/fd/0 -> /dev/pts/2



  1. I was wondering if all the files under /dev and its subdirectories
    are all file descriptors of devices?

  2. Why are there so many links from each other? For example, /dev/fd/0,
    /dev/stdin, /proc/self/fd/0 are all links to /dev/pts/2.

  3. If l in lrwx------ mean link, what does c in crw--w----
    mean?










share|improve this question




















  • 2





    And to answer #3, the c stands for character device, or character special. b stands for block special.

    – felixphew
    Dec 29 '14 at 19:48














47












47








47


39






$ ls -l /dev/stdin /dev/fd/0
lrwx------ 1 tim tim 64 2011-08-07 09:53 /dev/fd/0 -> /dev/pts/2
lrwxrwxrwx 1 root root 15 2011-08-06 08:14 /dev/stdin -> /proc/self/fd/0
$ ls -l /dev/pts/2 /proc/self/fd/0
crw--w---- 1 tim tty 136, 2 2011-08-07 09:54 /dev/pts/2
lrwx------ 1 tim tim 64 2011-08-07 09:54 /proc/self/fd/0 -> /dev/pts/2



  1. I was wondering if all the files under /dev and its subdirectories
    are all file descriptors of devices?

  2. Why are there so many links from each other? For example, /dev/fd/0,
    /dev/stdin, /proc/self/fd/0 are all links to /dev/pts/2.

  3. If l in lrwx------ mean link, what does c in crw--w----
    mean?










share|improve this question
















$ ls -l /dev/stdin /dev/fd/0
lrwx------ 1 tim tim 64 2011-08-07 09:53 /dev/fd/0 -> /dev/pts/2
lrwxrwxrwx 1 root root 15 2011-08-06 08:14 /dev/stdin -> /proc/self/fd/0
$ ls -l /dev/pts/2 /proc/self/fd/0
crw--w---- 1 tim tty 136, 2 2011-08-07 09:54 /dev/pts/2
lrwx------ 1 tim tim 64 2011-08-07 09:54 /proc/self/fd/0 -> /dev/pts/2



  1. I was wondering if all the files under /dev and its subdirectories
    are all file descriptors of devices?

  2. Why are there so many links from each other? For example, /dev/fd/0,
    /dev/stdin, /proc/self/fd/0 are all links to /dev/pts/2.

  3. If l in lrwx------ mean link, what does c in crw--w----
    mean?







linux devices file-descriptors






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jun 10 '17 at 23:53









Philip Kirkbride

2,65623897




2,65623897










asked Aug 7 '11 at 14:01









TimTim

28.9k79270495




28.9k79270495








  • 2





    And to answer #3, the c stands for character device, or character special. b stands for block special.

    – felixphew
    Dec 29 '14 at 19:48














  • 2





    And to answer #3, the c stands for character device, or character special. b stands for block special.

    – felixphew
    Dec 29 '14 at 19:48








2




2





And to answer #3, the c stands for character device, or character special. b stands for block special.

– felixphew
Dec 29 '14 at 19:48





And to answer #3, the c stands for character device, or character special. b stands for block special.

– felixphew
Dec 29 '14 at 19:48










3 Answers
3






active

oldest

votes


















69














Almost all the files under /dev are device files. Whereas reading and writing to a regular file stores data on a disk or other filesystem, accessing a device file communicates with a driver in the kernel, which generally in turn communicates with a piece of hardware (a hardware device, hence the name).



There are two types of device files: block devices (indicated by b as the first character in the output of ls -l), and character devices (indicated by c). The distinction between block and character devices is not completely universal. Block devices are things like disks, which behave like large, fixed-size files: if you write a byte at a certain offset, and later read from the device at that offset, you get that byte back. Character devices are just about anything else, where writing a byte has some immediate effect (e.g. it's emitted on a serial line) and reading a byte also has some immediate effect (e.g. it's read from the serial port).



The meaning of a device file is determined by its number, not by its name (the name matters to applications, but not to the kernel). The number is actually two numbers: the major number indicates which driver is responsible for this device, and the minor number allows a driver to drive several devices¹. These numbers appear in the ls -l listing, where you would normally find the file size. E.g. brw-rw---- 1 root disk 8, 0 Jul 12 15:54 /dev/sda → this device is major 8, minor 0.



Some device files under /dev don't correspond to hardware devices. One that exists on every unix system is /dev/null; writing to it has no effect, and reading from it never returns any data. It's often convenient in shell scripts, when you want to ignore the output from a command (>/dev/null) or run a command with no input (</dev/null). Other common examples are /dev/zero (which returns null bytes ad infinitum) /dev/urandom (which returns random bytes ad infinitum).



A few device files have a meaning that depends on the process that accesses it. For example, /dev/stdin designates the standard input of the current process; opening from has approximately the same effect as opening the original file that was opened as the process's standard input. Somewhat similarly, /dev/tty designates the terminal to which the process is connected. Under Linux, nowadays, /dev/stdin and friends are not implemented as character devices, but instead as symbolic links to a more general mechanism that allows every file descriptor to be referenced (as opposed to only 0, 1 and 2 under the traditional method); for example /dev/stdin is a symbolic link to /proc/self/fd/0. See How does /dev/fd relate to /proc/self/fd/?.



You'll find a number of symbolic links under /dev. This can occur for historical reasons: a device file was moved from one name to another, but some applications still use the old name. For example, /dev/scd0 is a symbolic link to /dev/sr0 under Linux; both designate the first CD device. Another reason for symbolic links is organization: under Linux, you'll find your hard disks and partitions in several places: /dev/sda and /dev/sda1 and friends (each disk designated by an arbitrary letter, and partitions according to the partition layout), /dev/disk/by-id/* (disks designated by a unique serial number), /dev/disk/by-label/* (partitions with a filesystem, designated by a human-chosen label); and more. Symbolic links are also used when a generic device name could be one of several; for example /dev/dvd might be a symbolic link to /dev/sr0, or it might be a link to /dev/sr1 if you have two CD readers and the second one is to be the default DVD reader.



Finally, there are a few other files that you might find under /dev, for traditional reasons. You won't find the same on every system. On most unices, /dev/log is a socket that programs use to emit log messages. /dev/MAKEDEV is a script that creates entries in /dev. On modern Linux systems, entries in /dev/ are created automatically by udev, obsoleting MAKEDEV.




¹ This is actually no longer true under Linux, but this detail only matters to device driver writers.






share|improve this answer


























  • Thanks! By "The meaning of a device file is determined by its number", do you mean its file descriptor?

    – Tim
    Aug 11 '11 at 2:54











  • @Tim: No, the numbers appear in ls -l listing where you normally find the file size, before the date, e.g. brw-rw---- 1 root disk 8, 0 Jul 12 15:54 /dev/sda → this device is major 8, minor 0. Device numbers don't come up often in practice, I just mentioned them to say what makes a device a device (most importantly, it's not the file name). A file descriptor number only has a meaning in a particular process.

    – Gilles
    Aug 11 '11 at 7:35











  • No, opening /dev/stdin (=> /proc/self/fd/0) on Linux has not the same effect as duplicating standard input. To see the difference, su - non_root_user, then exec 5</dev/stdin will fail with "Permission Denied", but exec 5<&0 will succeed. And it's not only that the new fd will be opened with different flags, everything about the file object ("open file description" in POSIX lingo) will be different (file pointer offset, non/blocking mode, etc).

    – mosvy
    13 hours ago



















14















  1. Yes - either directly or as symlinks - that is what /dev/ is for.

  2. For various purposes: sometimes for compatibility between naming schemes, sometimes it is necessary for the working environment - as in the example of /dev/stdin. This does not point statically to /dev/pts/2 or any other - just switch to another terminal and you'll see. /dev/stdin is the standard input of your current terminal session. That is also an example why it needs to be a symlink.

  3. See man mknod and info coreutils 'mknod invocation'. In general, c stands for a chararacter device type.






share|improve this answer





















  • 3





    "standard input of your current terminal session" is a bit ambiguous. /dev/stdin refers to the standard input of the process that will open it. Everything in /proc/$pid is process dependent data, and /proc/self is a kind of magic symlink pointing to the process' own data.

    – Stéphane Gimenez
    Aug 11 '11 at 1:09





















11














For your first question, they are not file descriptors, they are device files. (a.k.a. "dev nodes")



Those files are bound with the driver that is handling the device using major and minor numbers. (For instance, "136, 2" in your ls output refers to the device driver bound to major number 136, and specifies device #2 handled by that driver.)



The first letter of output of ls -l is type of the device in case of device files. If it is 'c' it is a character device, or if it is 'b', it is a block device.



For your second question, refer the above answer by rozcietrzewiacz.






share|improve this answer





















  • 1





    The "Introduction to Device Drivers" link appears to be broken.

    – Slothworks
    Aug 12 '15 at 7:26












Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f18239%2funderstanding-dev-and-its-subdirs-and-files%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























3 Answers
3






active

oldest

votes








3 Answers
3






active

oldest

votes









active

oldest

votes






active

oldest

votes









69














Almost all the files under /dev are device files. Whereas reading and writing to a regular file stores data on a disk or other filesystem, accessing a device file communicates with a driver in the kernel, which generally in turn communicates with a piece of hardware (a hardware device, hence the name).



There are two types of device files: block devices (indicated by b as the first character in the output of ls -l), and character devices (indicated by c). The distinction between block and character devices is not completely universal. Block devices are things like disks, which behave like large, fixed-size files: if you write a byte at a certain offset, and later read from the device at that offset, you get that byte back. Character devices are just about anything else, where writing a byte has some immediate effect (e.g. it's emitted on a serial line) and reading a byte also has some immediate effect (e.g. it's read from the serial port).



The meaning of a device file is determined by its number, not by its name (the name matters to applications, but not to the kernel). The number is actually two numbers: the major number indicates which driver is responsible for this device, and the minor number allows a driver to drive several devices¹. These numbers appear in the ls -l listing, where you would normally find the file size. E.g. brw-rw---- 1 root disk 8, 0 Jul 12 15:54 /dev/sda → this device is major 8, minor 0.



Some device files under /dev don't correspond to hardware devices. One that exists on every unix system is /dev/null; writing to it has no effect, and reading from it never returns any data. It's often convenient in shell scripts, when you want to ignore the output from a command (>/dev/null) or run a command with no input (</dev/null). Other common examples are /dev/zero (which returns null bytes ad infinitum) /dev/urandom (which returns random bytes ad infinitum).



A few device files have a meaning that depends on the process that accesses it. For example, /dev/stdin designates the standard input of the current process; opening from has approximately the same effect as opening the original file that was opened as the process's standard input. Somewhat similarly, /dev/tty designates the terminal to which the process is connected. Under Linux, nowadays, /dev/stdin and friends are not implemented as character devices, but instead as symbolic links to a more general mechanism that allows every file descriptor to be referenced (as opposed to only 0, 1 and 2 under the traditional method); for example /dev/stdin is a symbolic link to /proc/self/fd/0. See How does /dev/fd relate to /proc/self/fd/?.



You'll find a number of symbolic links under /dev. This can occur for historical reasons: a device file was moved from one name to another, but some applications still use the old name. For example, /dev/scd0 is a symbolic link to /dev/sr0 under Linux; both designate the first CD device. Another reason for symbolic links is organization: under Linux, you'll find your hard disks and partitions in several places: /dev/sda and /dev/sda1 and friends (each disk designated by an arbitrary letter, and partitions according to the partition layout), /dev/disk/by-id/* (disks designated by a unique serial number), /dev/disk/by-label/* (partitions with a filesystem, designated by a human-chosen label); and more. Symbolic links are also used when a generic device name could be one of several; for example /dev/dvd might be a symbolic link to /dev/sr0, or it might be a link to /dev/sr1 if you have two CD readers and the second one is to be the default DVD reader.



Finally, there are a few other files that you might find under /dev, for traditional reasons. You won't find the same on every system. On most unices, /dev/log is a socket that programs use to emit log messages. /dev/MAKEDEV is a script that creates entries in /dev. On modern Linux systems, entries in /dev/ are created automatically by udev, obsoleting MAKEDEV.




¹ This is actually no longer true under Linux, but this detail only matters to device driver writers.






share|improve this answer


























  • Thanks! By "The meaning of a device file is determined by its number", do you mean its file descriptor?

    – Tim
    Aug 11 '11 at 2:54











  • @Tim: No, the numbers appear in ls -l listing where you normally find the file size, before the date, e.g. brw-rw---- 1 root disk 8, 0 Jul 12 15:54 /dev/sda → this device is major 8, minor 0. Device numbers don't come up often in practice, I just mentioned them to say what makes a device a device (most importantly, it's not the file name). A file descriptor number only has a meaning in a particular process.

    – Gilles
    Aug 11 '11 at 7:35











  • No, opening /dev/stdin (=> /proc/self/fd/0) on Linux has not the same effect as duplicating standard input. To see the difference, su - non_root_user, then exec 5</dev/stdin will fail with "Permission Denied", but exec 5<&0 will succeed. And it's not only that the new fd will be opened with different flags, everything about the file object ("open file description" in POSIX lingo) will be different (file pointer offset, non/blocking mode, etc).

    – mosvy
    13 hours ago
















69














Almost all the files under /dev are device files. Whereas reading and writing to a regular file stores data on a disk or other filesystem, accessing a device file communicates with a driver in the kernel, which generally in turn communicates with a piece of hardware (a hardware device, hence the name).



There are two types of device files: block devices (indicated by b as the first character in the output of ls -l), and character devices (indicated by c). The distinction between block and character devices is not completely universal. Block devices are things like disks, which behave like large, fixed-size files: if you write a byte at a certain offset, and later read from the device at that offset, you get that byte back. Character devices are just about anything else, where writing a byte has some immediate effect (e.g. it's emitted on a serial line) and reading a byte also has some immediate effect (e.g. it's read from the serial port).



The meaning of a device file is determined by its number, not by its name (the name matters to applications, but not to the kernel). The number is actually two numbers: the major number indicates which driver is responsible for this device, and the minor number allows a driver to drive several devices¹. These numbers appear in the ls -l listing, where you would normally find the file size. E.g. brw-rw---- 1 root disk 8, 0 Jul 12 15:54 /dev/sda → this device is major 8, minor 0.



Some device files under /dev don't correspond to hardware devices. One that exists on every unix system is /dev/null; writing to it has no effect, and reading from it never returns any data. It's often convenient in shell scripts, when you want to ignore the output from a command (>/dev/null) or run a command with no input (</dev/null). Other common examples are /dev/zero (which returns null bytes ad infinitum) /dev/urandom (which returns random bytes ad infinitum).



A few device files have a meaning that depends on the process that accesses it. For example, /dev/stdin designates the standard input of the current process; opening from has approximately the same effect as opening the original file that was opened as the process's standard input. Somewhat similarly, /dev/tty designates the terminal to which the process is connected. Under Linux, nowadays, /dev/stdin and friends are not implemented as character devices, but instead as symbolic links to a more general mechanism that allows every file descriptor to be referenced (as opposed to only 0, 1 and 2 under the traditional method); for example /dev/stdin is a symbolic link to /proc/self/fd/0. See How does /dev/fd relate to /proc/self/fd/?.



You'll find a number of symbolic links under /dev. This can occur for historical reasons: a device file was moved from one name to another, but some applications still use the old name. For example, /dev/scd0 is a symbolic link to /dev/sr0 under Linux; both designate the first CD device. Another reason for symbolic links is organization: under Linux, you'll find your hard disks and partitions in several places: /dev/sda and /dev/sda1 and friends (each disk designated by an arbitrary letter, and partitions according to the partition layout), /dev/disk/by-id/* (disks designated by a unique serial number), /dev/disk/by-label/* (partitions with a filesystem, designated by a human-chosen label); and more. Symbolic links are also used when a generic device name could be one of several; for example /dev/dvd might be a symbolic link to /dev/sr0, or it might be a link to /dev/sr1 if you have two CD readers and the second one is to be the default DVD reader.



Finally, there are a few other files that you might find under /dev, for traditional reasons. You won't find the same on every system. On most unices, /dev/log is a socket that programs use to emit log messages. /dev/MAKEDEV is a script that creates entries in /dev. On modern Linux systems, entries in /dev/ are created automatically by udev, obsoleting MAKEDEV.




¹ This is actually no longer true under Linux, but this detail only matters to device driver writers.






share|improve this answer


























  • Thanks! By "The meaning of a device file is determined by its number", do you mean its file descriptor?

    – Tim
    Aug 11 '11 at 2:54











  • @Tim: No, the numbers appear in ls -l listing where you normally find the file size, before the date, e.g. brw-rw---- 1 root disk 8, 0 Jul 12 15:54 /dev/sda → this device is major 8, minor 0. Device numbers don't come up often in practice, I just mentioned them to say what makes a device a device (most importantly, it's not the file name). A file descriptor number only has a meaning in a particular process.

    – Gilles
    Aug 11 '11 at 7:35











  • No, opening /dev/stdin (=> /proc/self/fd/0) on Linux has not the same effect as duplicating standard input. To see the difference, su - non_root_user, then exec 5</dev/stdin will fail with "Permission Denied", but exec 5<&0 will succeed. And it's not only that the new fd will be opened with different flags, everything about the file object ("open file description" in POSIX lingo) will be different (file pointer offset, non/blocking mode, etc).

    – mosvy
    13 hours ago














69












69








69







Almost all the files under /dev are device files. Whereas reading and writing to a regular file stores data on a disk or other filesystem, accessing a device file communicates with a driver in the kernel, which generally in turn communicates with a piece of hardware (a hardware device, hence the name).



There are two types of device files: block devices (indicated by b as the first character in the output of ls -l), and character devices (indicated by c). The distinction between block and character devices is not completely universal. Block devices are things like disks, which behave like large, fixed-size files: if you write a byte at a certain offset, and later read from the device at that offset, you get that byte back. Character devices are just about anything else, where writing a byte has some immediate effect (e.g. it's emitted on a serial line) and reading a byte also has some immediate effect (e.g. it's read from the serial port).



The meaning of a device file is determined by its number, not by its name (the name matters to applications, but not to the kernel). The number is actually two numbers: the major number indicates which driver is responsible for this device, and the minor number allows a driver to drive several devices¹. These numbers appear in the ls -l listing, where you would normally find the file size. E.g. brw-rw---- 1 root disk 8, 0 Jul 12 15:54 /dev/sda → this device is major 8, minor 0.



Some device files under /dev don't correspond to hardware devices. One that exists on every unix system is /dev/null; writing to it has no effect, and reading from it never returns any data. It's often convenient in shell scripts, when you want to ignore the output from a command (>/dev/null) or run a command with no input (</dev/null). Other common examples are /dev/zero (which returns null bytes ad infinitum) /dev/urandom (which returns random bytes ad infinitum).



A few device files have a meaning that depends on the process that accesses it. For example, /dev/stdin designates the standard input of the current process; opening from has approximately the same effect as opening the original file that was opened as the process's standard input. Somewhat similarly, /dev/tty designates the terminal to which the process is connected. Under Linux, nowadays, /dev/stdin and friends are not implemented as character devices, but instead as symbolic links to a more general mechanism that allows every file descriptor to be referenced (as opposed to only 0, 1 and 2 under the traditional method); for example /dev/stdin is a symbolic link to /proc/self/fd/0. See How does /dev/fd relate to /proc/self/fd/?.



You'll find a number of symbolic links under /dev. This can occur for historical reasons: a device file was moved from one name to another, but some applications still use the old name. For example, /dev/scd0 is a symbolic link to /dev/sr0 under Linux; both designate the first CD device. Another reason for symbolic links is organization: under Linux, you'll find your hard disks and partitions in several places: /dev/sda and /dev/sda1 and friends (each disk designated by an arbitrary letter, and partitions according to the partition layout), /dev/disk/by-id/* (disks designated by a unique serial number), /dev/disk/by-label/* (partitions with a filesystem, designated by a human-chosen label); and more. Symbolic links are also used when a generic device name could be one of several; for example /dev/dvd might be a symbolic link to /dev/sr0, or it might be a link to /dev/sr1 if you have two CD readers and the second one is to be the default DVD reader.



Finally, there are a few other files that you might find under /dev, for traditional reasons. You won't find the same on every system. On most unices, /dev/log is a socket that programs use to emit log messages. /dev/MAKEDEV is a script that creates entries in /dev. On modern Linux systems, entries in /dev/ are created automatically by udev, obsoleting MAKEDEV.




¹ This is actually no longer true under Linux, but this detail only matters to device driver writers.






share|improve this answer















Almost all the files under /dev are device files. Whereas reading and writing to a regular file stores data on a disk or other filesystem, accessing a device file communicates with a driver in the kernel, which generally in turn communicates with a piece of hardware (a hardware device, hence the name).



There are two types of device files: block devices (indicated by b as the first character in the output of ls -l), and character devices (indicated by c). The distinction between block and character devices is not completely universal. Block devices are things like disks, which behave like large, fixed-size files: if you write a byte at a certain offset, and later read from the device at that offset, you get that byte back. Character devices are just about anything else, where writing a byte has some immediate effect (e.g. it's emitted on a serial line) and reading a byte also has some immediate effect (e.g. it's read from the serial port).



The meaning of a device file is determined by its number, not by its name (the name matters to applications, but not to the kernel). The number is actually two numbers: the major number indicates which driver is responsible for this device, and the minor number allows a driver to drive several devices¹. These numbers appear in the ls -l listing, where you would normally find the file size. E.g. brw-rw---- 1 root disk 8, 0 Jul 12 15:54 /dev/sda → this device is major 8, minor 0.



Some device files under /dev don't correspond to hardware devices. One that exists on every unix system is /dev/null; writing to it has no effect, and reading from it never returns any data. It's often convenient in shell scripts, when you want to ignore the output from a command (>/dev/null) or run a command with no input (</dev/null). Other common examples are /dev/zero (which returns null bytes ad infinitum) /dev/urandom (which returns random bytes ad infinitum).



A few device files have a meaning that depends on the process that accesses it. For example, /dev/stdin designates the standard input of the current process; opening from has approximately the same effect as opening the original file that was opened as the process's standard input. Somewhat similarly, /dev/tty designates the terminal to which the process is connected. Under Linux, nowadays, /dev/stdin and friends are not implemented as character devices, but instead as symbolic links to a more general mechanism that allows every file descriptor to be referenced (as opposed to only 0, 1 and 2 under the traditional method); for example /dev/stdin is a symbolic link to /proc/self/fd/0. See How does /dev/fd relate to /proc/self/fd/?.



You'll find a number of symbolic links under /dev. This can occur for historical reasons: a device file was moved from one name to another, but some applications still use the old name. For example, /dev/scd0 is a symbolic link to /dev/sr0 under Linux; both designate the first CD device. Another reason for symbolic links is organization: under Linux, you'll find your hard disks and partitions in several places: /dev/sda and /dev/sda1 and friends (each disk designated by an arbitrary letter, and partitions according to the partition layout), /dev/disk/by-id/* (disks designated by a unique serial number), /dev/disk/by-label/* (partitions with a filesystem, designated by a human-chosen label); and more. Symbolic links are also used when a generic device name could be one of several; for example /dev/dvd might be a symbolic link to /dev/sr0, or it might be a link to /dev/sr1 if you have two CD readers and the second one is to be the default DVD reader.



Finally, there are a few other files that you might find under /dev, for traditional reasons. You won't find the same on every system. On most unices, /dev/log is a socket that programs use to emit log messages. /dev/MAKEDEV is a script that creates entries in /dev. On modern Linux systems, entries in /dev/ are created automatically by udev, obsoleting MAKEDEV.




¹ This is actually no longer true under Linux, but this detail only matters to device driver writers.







share|improve this answer














share|improve this answer



share|improve this answer








edited 2 hours ago

























answered Aug 11 '11 at 0:48









GillesGilles

549k13111171631




549k13111171631













  • Thanks! By "The meaning of a device file is determined by its number", do you mean its file descriptor?

    – Tim
    Aug 11 '11 at 2:54











  • @Tim: No, the numbers appear in ls -l listing where you normally find the file size, before the date, e.g. brw-rw---- 1 root disk 8, 0 Jul 12 15:54 /dev/sda → this device is major 8, minor 0. Device numbers don't come up often in practice, I just mentioned them to say what makes a device a device (most importantly, it's not the file name). A file descriptor number only has a meaning in a particular process.

    – Gilles
    Aug 11 '11 at 7:35











  • No, opening /dev/stdin (=> /proc/self/fd/0) on Linux has not the same effect as duplicating standard input. To see the difference, su - non_root_user, then exec 5</dev/stdin will fail with "Permission Denied", but exec 5<&0 will succeed. And it's not only that the new fd will be opened with different flags, everything about the file object ("open file description" in POSIX lingo) will be different (file pointer offset, non/blocking mode, etc).

    – mosvy
    13 hours ago



















  • Thanks! By "The meaning of a device file is determined by its number", do you mean its file descriptor?

    – Tim
    Aug 11 '11 at 2:54











  • @Tim: No, the numbers appear in ls -l listing where you normally find the file size, before the date, e.g. brw-rw---- 1 root disk 8, 0 Jul 12 15:54 /dev/sda → this device is major 8, minor 0. Device numbers don't come up often in practice, I just mentioned them to say what makes a device a device (most importantly, it's not the file name). A file descriptor number only has a meaning in a particular process.

    – Gilles
    Aug 11 '11 at 7:35











  • No, opening /dev/stdin (=> /proc/self/fd/0) on Linux has not the same effect as duplicating standard input. To see the difference, su - non_root_user, then exec 5</dev/stdin will fail with "Permission Denied", but exec 5<&0 will succeed. And it's not only that the new fd will be opened with different flags, everything about the file object ("open file description" in POSIX lingo) will be different (file pointer offset, non/blocking mode, etc).

    – mosvy
    13 hours ago

















Thanks! By "The meaning of a device file is determined by its number", do you mean its file descriptor?

– Tim
Aug 11 '11 at 2:54





Thanks! By "The meaning of a device file is determined by its number", do you mean its file descriptor?

– Tim
Aug 11 '11 at 2:54













@Tim: No, the numbers appear in ls -l listing where you normally find the file size, before the date, e.g. brw-rw---- 1 root disk 8, 0 Jul 12 15:54 /dev/sda → this device is major 8, minor 0. Device numbers don't come up often in practice, I just mentioned them to say what makes a device a device (most importantly, it's not the file name). A file descriptor number only has a meaning in a particular process.

– Gilles
Aug 11 '11 at 7:35





@Tim: No, the numbers appear in ls -l listing where you normally find the file size, before the date, e.g. brw-rw---- 1 root disk 8, 0 Jul 12 15:54 /dev/sda → this device is major 8, minor 0. Device numbers don't come up often in practice, I just mentioned them to say what makes a device a device (most importantly, it's not the file name). A file descriptor number only has a meaning in a particular process.

– Gilles
Aug 11 '11 at 7:35













No, opening /dev/stdin (=> /proc/self/fd/0) on Linux has not the same effect as duplicating standard input. To see the difference, su - non_root_user, then exec 5</dev/stdin will fail with "Permission Denied", but exec 5<&0 will succeed. And it's not only that the new fd will be opened with different flags, everything about the file object ("open file description" in POSIX lingo) will be different (file pointer offset, non/blocking mode, etc).

– mosvy
13 hours ago





No, opening /dev/stdin (=> /proc/self/fd/0) on Linux has not the same effect as duplicating standard input. To see the difference, su - non_root_user, then exec 5</dev/stdin will fail with "Permission Denied", but exec 5<&0 will succeed. And it's not only that the new fd will be opened with different flags, everything about the file object ("open file description" in POSIX lingo) will be different (file pointer offset, non/blocking mode, etc).

– mosvy
13 hours ago













14















  1. Yes - either directly or as symlinks - that is what /dev/ is for.

  2. For various purposes: sometimes for compatibility between naming schemes, sometimes it is necessary for the working environment - as in the example of /dev/stdin. This does not point statically to /dev/pts/2 or any other - just switch to another terminal and you'll see. /dev/stdin is the standard input of your current terminal session. That is also an example why it needs to be a symlink.

  3. See man mknod and info coreutils 'mknod invocation'. In general, c stands for a chararacter device type.






share|improve this answer





















  • 3





    "standard input of your current terminal session" is a bit ambiguous. /dev/stdin refers to the standard input of the process that will open it. Everything in /proc/$pid is process dependent data, and /proc/self is a kind of magic symlink pointing to the process' own data.

    – Stéphane Gimenez
    Aug 11 '11 at 1:09


















14















  1. Yes - either directly or as symlinks - that is what /dev/ is for.

  2. For various purposes: sometimes for compatibility between naming schemes, sometimes it is necessary for the working environment - as in the example of /dev/stdin. This does not point statically to /dev/pts/2 or any other - just switch to another terminal and you'll see. /dev/stdin is the standard input of your current terminal session. That is also an example why it needs to be a symlink.

  3. See man mknod and info coreutils 'mknod invocation'. In general, c stands for a chararacter device type.






share|improve this answer





















  • 3





    "standard input of your current terminal session" is a bit ambiguous. /dev/stdin refers to the standard input of the process that will open it. Everything in /proc/$pid is process dependent data, and /proc/self is a kind of magic symlink pointing to the process' own data.

    – Stéphane Gimenez
    Aug 11 '11 at 1:09
















14












14








14








  1. Yes - either directly or as symlinks - that is what /dev/ is for.

  2. For various purposes: sometimes for compatibility between naming schemes, sometimes it is necessary for the working environment - as in the example of /dev/stdin. This does not point statically to /dev/pts/2 or any other - just switch to another terminal and you'll see. /dev/stdin is the standard input of your current terminal session. That is also an example why it needs to be a symlink.

  3. See man mknod and info coreutils 'mknod invocation'. In general, c stands for a chararacter device type.






share|improve this answer
















  1. Yes - either directly or as symlinks - that is what /dev/ is for.

  2. For various purposes: sometimes for compatibility between naming schemes, sometimes it is necessary for the working environment - as in the example of /dev/stdin. This does not point statically to /dev/pts/2 or any other - just switch to another terminal and you'll see. /dev/stdin is the standard input of your current terminal session. That is also an example why it needs to be a symlink.

  3. See man mknod and info coreutils 'mknod invocation'. In general, c stands for a chararacter device type.







share|improve this answer














share|improve this answer



share|improve this answer








edited Aug 10 '11 at 21:07

























answered Aug 7 '11 at 15:16









rozcietrzewiaczrozcietrzewiacz

29.6k47392




29.6k47392








  • 3





    "standard input of your current terminal session" is a bit ambiguous. /dev/stdin refers to the standard input of the process that will open it. Everything in /proc/$pid is process dependent data, and /proc/self is a kind of magic symlink pointing to the process' own data.

    – Stéphane Gimenez
    Aug 11 '11 at 1:09
















  • 3





    "standard input of your current terminal session" is a bit ambiguous. /dev/stdin refers to the standard input of the process that will open it. Everything in /proc/$pid is process dependent data, and /proc/self is a kind of magic symlink pointing to the process' own data.

    – Stéphane Gimenez
    Aug 11 '11 at 1:09










3




3





"standard input of your current terminal session" is a bit ambiguous. /dev/stdin refers to the standard input of the process that will open it. Everything in /proc/$pid is process dependent data, and /proc/self is a kind of magic symlink pointing to the process' own data.

– Stéphane Gimenez
Aug 11 '11 at 1:09







"standard input of your current terminal session" is a bit ambiguous. /dev/stdin refers to the standard input of the process that will open it. Everything in /proc/$pid is process dependent data, and /proc/self is a kind of magic symlink pointing to the process' own data.

– Stéphane Gimenez
Aug 11 '11 at 1:09













11














For your first question, they are not file descriptors, they are device files. (a.k.a. "dev nodes")



Those files are bound with the driver that is handling the device using major and minor numbers. (For instance, "136, 2" in your ls output refers to the device driver bound to major number 136, and specifies device #2 handled by that driver.)



The first letter of output of ls -l is type of the device in case of device files. If it is 'c' it is a character device, or if it is 'b', it is a block device.



For your second question, refer the above answer by rozcietrzewiacz.






share|improve this answer





















  • 1





    The "Introduction to Device Drivers" link appears to be broken.

    – Slothworks
    Aug 12 '15 at 7:26
















11














For your first question, they are not file descriptors, they are device files. (a.k.a. "dev nodes")



Those files are bound with the driver that is handling the device using major and minor numbers. (For instance, "136, 2" in your ls output refers to the device driver bound to major number 136, and specifies device #2 handled by that driver.)



The first letter of output of ls -l is type of the device in case of device files. If it is 'c' it is a character device, or if it is 'b', it is a block device.



For your second question, refer the above answer by rozcietrzewiacz.






share|improve this answer





















  • 1





    The "Introduction to Device Drivers" link appears to be broken.

    – Slothworks
    Aug 12 '15 at 7:26














11












11








11







For your first question, they are not file descriptors, they are device files. (a.k.a. "dev nodes")



Those files are bound with the driver that is handling the device using major and minor numbers. (For instance, "136, 2" in your ls output refers to the device driver bound to major number 136, and specifies device #2 handled by that driver.)



The first letter of output of ls -l is type of the device in case of device files. If it is 'c' it is a character device, or if it is 'b', it is a block device.



For your second question, refer the above answer by rozcietrzewiacz.






share|improve this answer















For your first question, they are not file descriptors, they are device files. (a.k.a. "dev nodes")



Those files are bound with the driver that is handling the device using major and minor numbers. (For instance, "136, 2" in your ls output refers to the device driver bound to major number 136, and specifies device #2 handled by that driver.)



The first letter of output of ls -l is type of the device in case of device files. If it is 'c' it is a character device, or if it is 'b', it is a block device.



For your second question, refer the above answer by rozcietrzewiacz.







share|improve this answer














share|improve this answer



share|improve this answer








edited Oct 23 '16 at 19:51









林果皞

2,4771534




2,4771534










answered Aug 10 '11 at 15:00









rulingmindsrulingminds

1112




1112








  • 1





    The "Introduction to Device Drivers" link appears to be broken.

    – Slothworks
    Aug 12 '15 at 7:26














  • 1





    The "Introduction to Device Drivers" link appears to be broken.

    – Slothworks
    Aug 12 '15 at 7:26








1




1





The "Introduction to Device Drivers" link appears to be broken.

– Slothworks
Aug 12 '15 at 7:26





The "Introduction to Device Drivers" link appears to be broken.

– Slothworks
Aug 12 '15 at 7:26


















draft saved

draft discarded




















































Thanks for contributing an answer to Unix & Linux Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f18239%2funderstanding-dev-and-its-subdirs-and-files%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Taj Mahal Inhaltsverzeichnis Aufbau | Geschichte | 350-Jahr-Feier | Heutige Bedeutung | Siehe auch |...

Baia Sprie Cuprins Etimologie | Istorie | Demografie | Politică și administrație | Arii naturale...

Nicolae Petrescu-Găină Cuprins Biografie | Opera | In memoriam | Varia | Controverse, incertitudini...