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;
}
$ 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
- I was wondering if all the files under
/dev
and its subdirectories
are all file descriptors of devices? - 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
. - If
l
inlrwx------
mean link, what doesc
incrw--w----
mean?
linux devices file-descriptors
add a comment |
$ 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
- I was wondering if all the files under
/dev
and its subdirectories
are all file descriptors of devices? - 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
. - If
l
inlrwx------
mean link, what doesc
incrw--w----
mean?
linux devices file-descriptors
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
add a comment |
$ 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
- I was wondering if all the files under
/dev
and its subdirectories
are all file descriptors of devices? - 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
. - If
l
inlrwx------
mean link, what doesc
incrw--w----
mean?
linux devices file-descriptors
$ 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
- I was wondering if all the files under
/dev
and its subdirectories
are all file descriptors of devices? - 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
. - If
l
inlrwx------
mean link, what doesc
incrw--w----
mean?
linux devices file-descriptors
linux devices file-descriptors
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
add a comment |
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
add a comment |
3 Answers
3
active
oldest
votes
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.
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 inls -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
, thenexec 5</dev/stdin
will fail with "Permission Denied", butexec 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
add a comment |
- Yes - either directly or as symlinks - that is what
/dev/
is for. - 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. - See
man mknod
andinfo coreutils 'mknod invocation'
. In general,c
stands for a chararacter device type.
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
add a comment |
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.
1
The "Introduction to Device Drivers" link appears to be broken.
– Slothworks
Aug 12 '15 at 7:26
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
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 inls -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
, thenexec 5</dev/stdin
will fail with "Permission Denied", butexec 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
add a comment |
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.
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 inls -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
, thenexec 5</dev/stdin
will fail with "Permission Denied", butexec 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
add a comment |
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.
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.
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 inls -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
, thenexec 5</dev/stdin
will fail with "Permission Denied", butexec 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
add a comment |
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 inls -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
, thenexec 5</dev/stdin
will fail with "Permission Denied", butexec 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
add a comment |
- Yes - either directly or as symlinks - that is what
/dev/
is for. - 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. - See
man mknod
andinfo coreutils 'mknod invocation'
. In general,c
stands for a chararacter device type.
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
add a comment |
- Yes - either directly or as symlinks - that is what
/dev/
is for. - 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. - See
man mknod
andinfo coreutils 'mknod invocation'
. In general,c
stands for a chararacter device type.
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
add a comment |
- Yes - either directly or as symlinks - that is what
/dev/
is for. - 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. - See
man mknod
andinfo coreutils 'mknod invocation'
. In general,c
stands for a chararacter device type.
- Yes - either directly or as symlinks - that is what
/dev/
is for. - 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. - See
man mknod
andinfo coreutils 'mknod invocation'
. In general,c
stands for a chararacter device type.
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
add a comment |
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
add a comment |
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.
1
The "Introduction to Device Drivers" link appears to be broken.
– Slothworks
Aug 12 '15 at 7:26
add a comment |
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.
1
The "Introduction to Device Drivers" link appears to be broken.
– Slothworks
Aug 12 '15 at 7:26
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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