lkml.org 
[lkml]   [1999]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: My $0.02 on devd and devfs
Date
H. Peter Anvin writes:
> The right solution -- which the devfs people have correctly identified
> -- is a user-space daemon. However, once you have the user-space
> daemon, "devd", I believe you neither need nor want the virtual
> filesystem, in the general case. However, I can understand that in
> some configurations (like embedded systems) it may be desirable.

[Despite my similar email address, I've never met Richard, nor used devfs, ]
[although it is interesting to see people in Calgary working on Linux... ]

I've read a lot of the discussion about devfs pros and cons, and
possible solutions. One of the recurring themes I've noticed is the
desire for separation of automatic device detection from a virtual
filesystem. Some of the supporters point to Irix and Solaris for
examples of how it can be done, but I haven't seen any mention of the
methods AIX uses for dynamic device configuration, so I thought I would
mention it here as another data point for people to take into
consideration (I work with AIX a lot).

* * *

AIX uses a real /dev filesystem as part of the root partition to store
device inodes. This allows for the setting of permissions, ACLs, etc to
be persistent across reboots, backed up, etc, and they are available at
the earliest stages of boot. Device major and minor numbers are (for my
understanding at least) assigned on demand for a class of devices with a
16/16 split (for example all SCSI disks are assigned a single major, but
the major can change from one system to the next).

Devices are added to the system by running a command called "cfgmgr" (which
is also run at boot), which starts a "recursive scan" of all devices on the
system, and may add new device inodes into /dev. The initial device scan
works by querying the system planar about what type and number of devices it
has (e.g. PCI bus, ISA bus, keyboard+mouse ports, serial, etc) which are
output to stdout, and then in turn a configuration script is run for each of
these devices to see if they have child devices (e.g. PCI bus has an ethernet
card, dual channel SCSI card, SSA disk adapter), which in turn spit out more
child devices which get configured by their config scripts (if they are new
to the system), etc. It is, of course, possible to run the configuration on
only the PCI bus, or only for SCSI disks, if you know what was added, and
don't want to run the whole configuration (which might take 20-30 seconds
for a system with a hundred disks).

Disks, network adapters, serial ports, etc, all have nice symbolic names
like hdisk0, en0, tty0, which are persistent across reboots because the
internal details which map a device to a name are stored in an on-disk
database, so we know hdisk0 is really PCI bus 0, slot 7, controller 0,
target, lun, etc, and this information is mapped to a device minor. If
cfgmgr is run on the system, and a new device is detected, it gets the
next free name for devices in its class (e.g. hdisk205) permanently assigned,
and a config script is run which will make the /dev inode, set default
parameters for the device, etc. If a device already exists in the
configuration database, nothing is done to the device or the database.

Devices can be either in the "available" state, or the "defined" state (which
means that configuration information about the device is kept, even though
the device is not currently available). To temporarily remove a device from
the system, you run "rmdev -l <name>", which puts it in the defined state, and
it is inaccessible (much like "ifconfig down <eth0>" should be). To get rid
of a device permanently, you run "rmdev -d -l <name>", which will remove the
config info from the database, and delete the inode.

Devices have default parameters set when they are initially configured, but
these can be set in the database with "chdev -l <name> -a option=value" (e.g.
"chdev -l ent0 -a full_duplex=yes" or "chdev -l scsi1 -a enable_wide=no").
Devices are listed via "lsdev -Cc <class>" (e.g. "lsdev -Cc disk" or
"lsdev -Cc adapter" (there are optional sub-classes as well)). Device
attributes can be listed via "lsattr -El <device>" (e.g. "lsdev -El eth0"
tells me hardware information like interrupts, I/O addresses, alternate
MAC address, duplex, etc - types of information specific to a class of
device).

* * *

While the system isn't as dynamic as devfs sounds like (i.e. /dev entries
aren't added and removed on the fly), it works very well for systems with
hundreds of disks, serial ports, etc. The fact that it is a physical
filesystem which keeps device permissions is important, as is the fact that
the device inodes can be backed up via tar/dump/whatever. It is actually
a good thing that devices missing from the system are kept across reboots
(i.e. you need to manually remove them), so tape drive density settings
aren't lost, and the fact that you had a disk called hdisk74 which is
"defined" but not "available" helps when you are trying to figure out why
your database won't start...

If there was anything that could be improved with this is if a parent
device has a method of notifying the kernel that a new child has arrived,
it could automatically run the configuration method for it (e.g. USB, or
SSA disk loops which have their own daemons monitoring the topology). I
suppose that you could also "clean up" the unavailable devices after a
certain time (like cleaning /tmp), but this should be a user-space thing
run via cron or whatever, based on the time the device became unavailable,
and definitely not something automatic.


Hopefully someone finds this brief tutorial helpful in some way. The details
are not fully covered here (like the fact that EVERYTHING is configured via
the database, and the fact that AIX LVM doesn't really CARE what the disk
devices are called), but it does cover what's pertinent to this discussion,
which is /dev inodes and device addition/removal. I know some people hate
AIX as the devil child of Unix, but from an administrative point of view, I
like it. I'm not advocating this on anyone else, it's just information.

Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.099 / U:0.304 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site