I've read a ton on Linux books this past year. But two things that are never
explained well are:

What is a device? By that I mean what are the entries in /dev (like /dev/cdrom
or /dev/fd0 etc.) I don't mean what they stand for, but WHAT are they?

Then, what is a mountpoint? What is /mnt/cdrom mean?

I know what a file is. It holds data... text, binary, etc. And I know that
filenames and directory names are entries in an inode table.

I don't understand what a device is, what a mountpoint is and what the
relationship between them is.

The books all say "In Linux everything is a file" and then they go off into
gibberish-land... I often think the AUTHORS don't know the answer!

I ask here because Slackers really KNOW some %^&* and I won't get
misinformation like I would in comp.os.linux.xxxx.

So if some kind soul has a few minutes to either give a short explanation...
or point me to an article that explains this for idiots I'd be appreciative.
And I'm sure I'm not the ONLY person confused on /dev and /mnt.

Al C.

On Wed, 05 Jan 2005 04:00:39 +0000, Al. C wrote:

> I've read a ton on Linux books this past year. But two things that are never
> explained well are:
>
> What is a device? By that I mean what are the entries in /dev (like /dev/cdrom
> or /dev/fd0 etc.) I don't mean what they stand for, but WHAT are they?
>
> Then, what is a mountpoint? What is /mnt/cdrom mean?
>
> I know what a file is. It holds data... text, binary, etc. And I know that
> filenames and directory names are entries in an inode table.
>
> I don't understand what a device is, what a mountpoint is and what the
> relationship between them is.
>
> The books all say "In Linux everything is a file" and then they go off into
> gibberish-land... I often think the AUTHORS don't know the answer!
>
> I ask here because Slackers really KNOW some %^&* and I won't get
> misinformation like I would in comp.os.linux.xxxx.
>
> So if some kind soul has a few minutes to either give a short explanation...
> or point me to an article that explains this for idiots I'd be appreciative.
> And I'm sure I'm not the ONLY person confused on /dev and /mnt.
>
> Al C.

In Linux, everything is a file - that's what makes things so easy to
handle. Something like /dev/hda1 is a 'block special' file as opposed to a
'character' file (like a text file). /dev/cdrom is a special file for
handling the cdrom drive. A mountpoint, like /mnt/cdrom is also a file -
a directory - if it didn't already exist, you would do 'mkdir /mnt/cdrom'
to make it - it is simply a place to mount the contents of the cdrom. /dev
and /mnt are both directories - the entries in /dev are special files for
handling devices - the entries in /mnt are files, too - they are empty
(usually, but not necessarily) which are places to 'mount' or access the
contents of file structured devices.

Hope that helps a little - I don't know of a good discussion, you might
try looking in www.tldp.org or www.yolinux.com.

Al. C <no.spam.acanton@take.out.adams-blake.no.spam.com> wrote:
>
> I don't understand what a device is, what a mountpoint is and what the
> relationship between them is.
>

Does the concept of major and minor device numbers make sense?

This might be a good place to start:

<http://wks.uts.ohio-state.edu/sysadm_course/html/sysadm-208.html>

Plus digging through the kernel source, or something that explains
the kernel source. This is most likely what you need for the level
of understanding that you want.

This link might help:

<http://www.tldp.org/LDP/tlk/tlk.html>

Check out the device drivers section.

- Kurt

Al. C wrote:

> I've read a ton on Linux books this past year. But two things that are
> never explained well are:
>
> What is a device? By that I mean what are the entries in /dev (like
> /dev/cdrom or /dev/fd0 etc.) I don't mean what they stand for, but WHAT
> are they?
>
> Then, what is a mountpoint? What is /mnt/cdrom mean?
>

A mountpoint is a place where you can attach something to your directory
tree.
For instance when I type mount /dev/sr0 /mnt/cdrom
I make it possible to read the contents of the cd/dvd reader in /mnt/cdrom.

A device is something invented to drive me crazy. You too.
For instance my cd/dvd reader/writer is known as lun0,0,0
and /dev/cdrom /dev/dvd /dev/hdc /dev/scd0 /dev/sr0 and maybe another one.

Those who write software live in another world.

~kurt wrote:

> http://www.tldp.org/LDP/tlk/tlk.html

This is quite good. It will take me a while to wade through it, but eventually
I will... a few pages a day. It reminds me of a book that I read about 10 or
15 years ago. It was well-known so you might remember it. It was also used as
a college text. The title was something like "How Operating Systems Work" and
the author actually took you on a journey of BUILDING (through pseudo code) a
mini-unix OS. I wish I still had that book. It was one of the best comp. sci.
tomes I have ever read.

I started in computers with EDS in 1974 where we did everything in IBM 360
assembler. I think I could still code in that! (I believe an MVC is still a
"D2") When you start at that level, you get a good education and appreciation
for the technology and about what an OS does and how to talk to it. But I
never got down to the device driver level. I'd really like to learn more
about the internals of Linux.... if only I had the time.

Al C.

In article <2aLCd.8957$7n1.692697@news20.bellglobal.com>, myob@nomail.ru
says...
>
>Al. C wrote:
>
>> I've read a ton on Linux books this past year. But two things that are
>> never explained well are:
>>
>> What is a device? By that I mean what are the entries in /dev (like
>> /dev/cdrom or /dev/fd0 etc.) I don't mean what they stand for, but WHAT
>> are they?
>>
>> Then, what is a mountpoint? What is /mnt/cdrom mean?
>>
>
>A mountpoint is a place where you can attach something to your directory
>tree.
>For instance when I type mount /dev/sr0 /mnt/cdrom
>I make it possible to read the contents of the cd/dvd reader in /mnt/cdrom.
>
>A device is something invented to drive me crazy. You too.
>For instance my cd/dvd reader/writer is known as lun0,0,0
>and /dev/cdrom /dev/dvd /dev/hdc /dev/scd0 /dev/sr0 and maybe another one.
>
>Those who write software live in another world.
Hello from the Eighth Doctor
Exactly right. According to the gang who's responsible for keeping IBM mainframes
running, they contend that Linux _is_Linux, that it matters not that they are S/390
machines rather then Intel, and get this, same programs, and commands.

Each device driver exists, within reason, even Slackware runs there. While you can't
run an Xserver on the big guy, (No head!), you can configure him to serve
Xsessions, and setup something appropriate on your local box. A Vnc session, and
the server running there, or the Cygwin Xserver talking to the big guy, using SSH.

So what it boils down to is that the mountpoints we use to attach CDs, and USB
devices, are the same regardless of which distribution we use.
----
Gregg drwho8 atsign att dot net

"Al. C" <no.spam.acanton@take.out.adams-blake.no.spam.com> wrote:
>I've read a ton on Linux books this past year. But two things that are never
>explained well are:
>
>What is a device? By that I mean what are the entries in /dev (like /dev/cdrom
>or /dev/fd0 etc.) I don't mean what they stand for, but WHAT are they?
>
>Then, what is a mountpoint? What is /mnt/cdrom mean?
>
>I know what a file is. It holds data... text, binary, etc. And I know that
>filenames and directory names are entries in an inode table.
>
>I don't understand what a device is, what a mountpoint is and what the
>relationship between them is.
>
>The books all say "In Linux everything is a file" and then they go off into
>gibberish-land... I often think the AUTHORS don't know the answer!
>
>I ask here because Slackers really KNOW some %^&* and I won't get
>misinformation like I would in comp.os.linux.xxxx.
>
>So if some kind soul has a few minutes to either give a short explanation...
>or point me to an article that explains this for idiots I'd be appreciative.
>And I'm sure I'm not the ONLY person confused on /dev and /mnt.
>
>Al C.

I laughed when I read that... then I read the answers you are
getting. Seems I was naive to think the questions were naive.

First, the "everything is a file" is *not* a Linux concept, but
rather was inherent in *UNIX* right from the beginning, where it
was indeed a new idea. Your concept of what a "file" is, is too
limited! (Which is one reason for the confusion.)

An Operating System provides services to "user" applications,
and the idea behind "everything is a file" is to make the
application's interface to everything just the same as if it
were a file rather than implementing a totally distinct set of
functions for each and every type of interface, which is exactly
the way OS's were written prior to UNIX.

For example, we have an OS that provides "system calls" (in the
C programming language the functions in Section 2 of the man
pages access those services), and for files we have a basic set
of functions (e.g., open(), read(), write(), lseek() and
close()) to allow programs to manipulate files. *That* is the
interface the creators of UNIX wanted to use for *everything*.
(They did not succeed immediately in doing so, but modern unix
OS's pretty much do, with a few exceptions.)

What's all that mean? Well, if we have a printer or a modem, we
want to be able do IO using those open/read/write/close
functions! There are other things too... networks, pipes,
buffers, and for that matter processes themselves as well as the
kernel itself, which can be accessed using the "file interface"!

That works because there are many types of "files" and while at
the application programming level we rarely are ever much
concerned with different file types, inside the kernel each of
those functions that deal with files are actually doing *very*
*different* things for each different type of file. Hence if
your applications program wants input from a FIFO, from a disk
file, and from a modem, the way the read() function is used is
identical... but inside the kernel what happens is totally
different. The read() function has the same name, but it
executes different code for each of those "files". The whole
point of the UNIX concept of "everything is a file" is to hide
that difference from application programmers and users.

Whenever you do an /ls/ command using the /-l/ option you see a
display that shows the file type as part of the string that also
shows the permissions. The man page for /ls/ says (reformatted
for emphasis):

"The file types are as follows:

- for an ordinary file,
d for a directory,
b for a block special device,
c for a character special device,
l for a symbolic link,
p for a fifo,
s for a socket."

OK? Now you can see that the kernel uses "file" system calls to
do several different things, depending on what "type" of file.

One of those things is access to hardware via "device special"
files, the "b" and "c" types in the list above. Generally
device special files are all kept in the /dev directory, and a
quick check there shows how diverse this "everything is a file"
concept has gotten! We can access the computer's memory, every
hardware device from hard disks to printers, and a bazillion
other things, in an application by using the same functions that
are used to access just an "ordinary file".

Prior to UNIX, it was much more likely that an OS would provide
a different system call for each type of device; which means
each of the "major" device numbers used by device special files
in /dev would probably have had a totally separate function for
each of read(), write() and so on. It worked fine to begin
with, but obviously would be *way* out of hand by today!

So that is what a "device" is! It is the magic hidden inside
the kernel to allow one universal, simplified, method of access
to *anything* for input/output. It is the part of the kernel
which decides what the read() function, for example, will
actually do when called for *that* particular file. A "device
driver" is the code to provide the functionality. It extends the
kernel's list of "file types" by providing a "file interface" for
any given hardware.

Hence you can only call read() on /dev/xyz if there is a
"driver" in the kernel for an xyz. And of course the driver
must actually find whatever hardware it is supposed to
communicate with too.

On to "mountpoint"...

Directories are one of those "different" types of files too.
And a mount point is nothing other than a directory!

A mount point is a directory that is arbitrarily used as the
place where a "filesystem" is attached to the directory tree.
But there is nothing special about it, as any directory can be
used as a mount point.

A "filesystem" is just more kernel magic used to hide messy
details from application level programming. It usually provides
a standardized view of "files" available on some storage device,
but for example sometimes it provides a view of "files"
(information) available from the kernel!

Regardless, the "mount" system call attaches the filesystem to
the directory tree, which makes those "files" available via the
interface discussed above. A filesystem can be mounted on *any*
directory, and any directory that has a filesystem mounted on it
is then called a "mount point".

Now, consider two ideas...

If you have a directory which contains a list of files available
on one storage device, what happens if you then mount another
filesystem on that particular directory? Can you access the
files that were available prior to mounting the new filesystem?
Are they still there? Hmmmm... (Try it!)

But another idea is actually much more interesting! The
"everything is a file" concept actually means "everything that
is local to this computer is a file". Things that are networked
don't fit quite so well, though certainly even that is partially
interfaced as a "file". (Networks aren't well adapted, but
network connections, once they are set up, are.) So... what if
the paradigm is change to "everything is a network"? The same
people who came up with "everything is a file" have also spent a
couple decades or so researching the concept of viewing
everything as a network too.

--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com

On 2005-01-05, Al. C <no.spam.acanton@take.out.adams-blake.no.spam.com> wrote:
[snip]
> I started in computers with EDS in 1974 where we did everything in IBM 360
> assembler. I think I could still code in that! (I believe an MVC is still a
> "D2") When you start at that level, you get a good education and appreciation
> for the technology and about what an OS does and how to talk to it. But I
> never got down to the device driver level. I'd really like to learn more
> about the internals of Linux.... if only I had the time.

Then you should read "Understanding the Linux Kernel" -- it's a great
book about Linux internals. You'll need some time for it, though .

--
Alexander Ulyanov, maintainer of PosBand roguelike
E-mail: uav AT urmail DOT ru Web: http://orthanc.chat.ru/pos/
Anyone who is capable of getting themselves made President should on no
account be allowed to do the job. -- The Hitchhiker's Guide To The Galaxy

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In alt.os.linux.slackware, Al. C dared to utter,
> What is a device? By that I mean what are the entries in /dev (like /dev/cdrom
> or /dev/fd0 etc.) I don't mean what they stand for, but WHAT are they?
> Then, what is a mountpoint? What is /mnt/cdrom mean?

Excellent question.

Device files are a little difficult to explain, and I don't fully
understand them, but I'll give it my best shot (though I think kurt's
pretty much answered the question). Device files are special files that
read and write to the kernel, rather than to themselves.

So, you might $(cat some_file) and the kernel makes a system call to
the filesystem, finds the file, then sends its contents to the shell.
Now if you were to say $(cat /dev/urandom) the kernel makes a system
call to its random number generator. How it does this is of course the
million dollar question. Some one correct me if I'm wrong, but the
kernel portions up its internals into major sections, then subsections
represented by major and minor numbers respectively.

So /dev/urandom has a different major and minor number combination than
/dev/hda. This simply tells the kernel where to read/write information
from.

Now mount points are easy. A mount point is just an empty[0] directory
where you mount (think graft) a filesystem. So there's really nothing
special about where the mount point is[1]. You can just as easily mount
/dev/cdrom at /mnt/hd as you can at /mnt/cdrom.

[0] Actually it need not be empty, but out of convention it is. If you
mount a filesystem over a non-empty directory the contents of that
directory are hidden until you umount.
[1] For that matter there's nothing special about where device files go
either. You can have /home/hda1 if you wanted, but convention puts them
all in /dev.

- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB2/7llKR45I6cfKARAsDGAJ9L6pqG3kURq0LqTHIHobg0y4CKSgCg iP4b
P3Asumy1H+J5JrZk7DM/jhk=
=OAIw
-----END PGP SIGNATURE-----

Floyd L. Davidson wrote:

[snip of excellent article]

Thanks for the wonderful explanation of these concepts. I think Hicks and
company ought to add an appendix to the new 'good book' called "A Few Linux
Concepts for the Advanced Slacker" (or something like that) and add your
posting to this section. Obviously, this section can be a "growing" thing as
I'm sure more and more "experts" will be willing to contribute postings like
yours when asked the question.

Thanks again. To paraphrase Scarlet, (standing on a hill with a handful of
dirt and a ominous sky)

"I will never be intimidated by /dev again!"

(Music comes up, camera retreats, curtains come down, intermission.) What am I
talking about? Someone must be old enough to know. Sounds like "Lives in
bin". I think Alan Hicks built his house there!!! Didn't any of you kids
ever see anything at the movies besides Star Trek or Matrix? :-) God, I'm
old!

Al C.