Thank you for the detailed explanation. I'll read through
it tonight.
On Tue, 21 Jan 2003 02:39:07 +0800
"Marton Kadar" <marton.kadar@xxxxxxxx> wrote:
Hi,
Just to share my own idea of things in devfs/devfsd:
If a program needs to talk to a device, it opens a device
node in the filesystem. The question is, what is the link
between the device node and the driver code?
There is a reference file in the linux kernel sources:
Documentation/devices.txt. This contains the assigned
numbers of all devices. This file is a layer of
conventions from before devfs.
There was another layer of conventions, (I think it is
also more or less documented in devices.txt) that of the
device node names under /dev. So there was a convention,
that your 2nd SCSI cd-rom drive has major number X and
minor number Y, and another convention, that it should be
represented by node sr1 under /dev.
The number convention is used by the device drivers in
the kernel. If you wanted to write a device driver for an
scsi cdrom drive, you had to look up the major and minor
numbers in this table, and let your code register itself
under these numbers.
The node-name convention is used by user space programs.
So if you wanted to write a user space program which
needed to talk to the 2nd SCSI cdrom drive, it had to
look for it at /dev/sr1.
But in fact, you could create a device node ANYWHERE in
your disk-based filesystem, and assign some device major
and minor numbers to it, and then you could configure
your user application to use that device node. When the
program opens the device node for communication, the
kernel takes the major number and checks which device
driver registered itself under that number, and lets that
driver handle things.
There were two changes that devfs mainly introduced:
- allowed for not using device numbers at all, as there
were problems with all the numbers being used up
- changed the device node naming convention to better
reflect the tree-like structure of interfaces, buses,
adapters etc.
We refer to the new node naming convention as the devfs
namespace.
So a modern kernel device driver may choose to register
itself only by the path and name of the devices it will
handle.
A modern user space program should be ready to find the
device nodes also under their new filesystem location.
The link between drivers and device nodes is no longer
established by the major and minor numbers, but the
device node NAME ITSELF is the link.
Up till now there's been no word about devfsd. In an
utopistic world
- all your device drivers register themselves by name in
the devfs namespace,
- the kernel mounts the devfs filesystem under /dev at
boot time, thus making the device nodes available to
programs,
- and all your programs know where to find them.
In the real world there are old device drivers (less and
less the case) and for some time to come there will be
old user space programs. Old programs expect the device
nodes at the old locations, but they are no longer there.
To handle this issue, devfsd was invented.
If you look at the file names in a mounted devfs
filesystem, you notice one thing which is not a device,
the devfsd control socket. When a device driver in the
kernel registers itself, two things happen: the device
node is created in the filesystem, AND an event signal
(REGISTER) is sent through the devfsd control socket. IF
devfsd is running, attached to the socket, it catches the
signal, looks at /etc/devfsd.conf, and carries out the
specified helper action(s).
One special helper action is MAKEOLDCOMPAT which means
that a symlink has to be created according to the OLD
/dev device node naming conventions, which points to the
NEW ("real") devfs-compliant device node location. This
allows old programs find the newly registered device
where they expect it.
Another kind of signal arrives from the kernel (LOOKUP
event), when it is asked to open a file(device node) in
the devfs filesystem, but the file is not there. This is
typically the case when a kernel module has not been
loaded yet, so the driver could not register itself yet
under that path. So devfsd can try to load the desired
module if it finds such instructions (MODLOAD action) in
/etc/devfsd.conf.
OK, this was rather lengthy. It just wanted to be a
framework for your thinking. There are lots of details
and particulars that you need to check yourself.
Marton
----- Original Message -----
From: "Brett I. Holcomb" <brettholcomb@xxxxxxxxxxx>
Date: Fri, 17 Jan 2003 22:54:49 -0500
To: devfs@xxxxxxxxxxx
Subject: Re: SCSI Tapes and devfs
It's the backup program. I created the symlink
ln -s /dev/sg/c1b0t1u0 /dev/auto_changer0
and it stays UNTIL I run the backup program an then the
link disappears.
As long as I tell the backup program to use /dev/sg2
for the changer
device everything works! I'll contact the backup people
to see what
they are doing.
However, let me summarize my lack of knowledge here so I
don't get too
far off track.
1. Don't mess with dev (don't create symlinks in it
manually)
2. I THINK I use /etc/devfsd.conf to create the entries
in /dev when
the device has an event happen to it?. So what I should
do to create
the autochanger is go to /etc/devfsd.conf and put in
something like the
CD line to create a symlink. I should have done that
for the tape, too
but somehow it got created anyway. Is this correct -
use
/etc/devfsd.conf for creating /dev entries.
3. What have I missed?
Thank you.
--
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup
Meet Singles
http://corp.mail.com/lavalife
|