This is mostly addressed to R.Gooch...
I have started using 'devfs' quite recently (kernel 2.4.6), as I was
scandalized by the number of entries in '/dev/' in most common
distributions (my current SuSE 7.2 has over 2,000, Mandrake 7.1 had over
6,000), as you probably were when you decided to write 'devfs'.
I think it's fine, but there are some small details...
* One thing that did bite me is that entries under 'discs/', 'cdroms/'
and 'tapes/' are not numbered, as suggested in the FAQ, consecutively
starting from zero; right now I have 'cdrom0' and 'cdrom2', and at
some point I had 'tape1' and 'tape5', for example.
It seems to depend on whether the number of times the modules related
to the devices have been loaded/unloaded.
Now, I understand that every time a device driver modules is loaded it
might choose for itself a higher number; in particular I understand
that the SCSI HA modules choose a higher host number every time they
are loaded (actually, do they in recent kernels?).
But the numbers under 'discs/', 'cdroms/' and 'tapes/' should be
strictly sequential starting with 0, as they are supposed to represent
the ``nth'' device of that type.
Also, the behaviour is somewhat inconsistent; for example I have a
SCSI HA with a CD reader/writer and two tape units on it; my ATA setup
is two discs and one CD/DVD reader.
Just after booting I had the following devices:
discs/0 discs/1
cdroms/0 cdroms/2
tapes/0 tapes/1
and the SCSI HA was listed under '/dev/scsi/host1' (which is right as I
also have a virtual 'idescsi' HA for experimenting), which is listed
under 'proc' as '/proc/scsi/sym53c8xx/1'.
I have unloaded it and reloaded it a couple of times and now the
situation is:
------------------------------------------------------------------------
# ls -ld discs/* cdroms/* tapes/*
lr-xr-xr-x 1 root root 33 Jan 1 1970 cdroms/cdrom0 ->
../ide/host0/bus0/target1/lun0/cd
lr-xr-xr-x 1 root root 34 Jan 1 1970 cdroms/cdrom2 ->
../scsi/host1/bus0/target3/lun0/cd
lr-xr-xr-x 1 root root 30 Jan 1 1970 discs/disc0 ->
../ide/host0/bus0/target0/lun0
lr-xr-xr-x 1 root root 30 Jan 1 1970 discs/disc1 ->
../ide/host0/bus1/target0/lun0
lr-xr-xr-x 1 root root 31 Jan 1 1970 tapes/tape4 ->
../scsi/host1/bus0/target5/lun0
lr-xr-xr-x 1 root root 31 Jan 1 1970 tapes/tape5 ->
../scsi/host1/bus0/target6/lun0
------------------------------------------------------------------------
which is somewhat bizarre: on every reload the tapes have increased
their number by 2, but the cdrom numbers, even if oddly 0 and 2, have
stayed the same.
* Another possible bug: in the manuals page for 'devfsd' in the section
'CAVEATS' you mention the danger of using a ``devname'' like "cdrom",
as it is not anchored by either/both '^' or '$'.
However the sample 'devfsd.conf' and some of examples in the FAQ use
similarly dangerous syntax. I have rewritten these REs in what I think
is a safer/nicer way (down to details like replacing '.*' with '^.'),
making essentially all ``devnames'' start with the '^' anchor, which I
think should be the case. I have attached it.
* The documentation is rather vague on what a regular expression is
(there are _many_ flavours) and what kind of syntax the 'devfsd'
configuration files can have; for example it is not clear if names
with blanks or other special characters can be specified in
'/etc/devfsd.conf'.
* Against your advice :-), I do use entries like '/dev/modem',
'/dev/tape', '/dev/cdrom'; I have attached a sample file that sets
them up. I use 'COPY' for brevity. It would be nice to have built in
'SYMLINK', and 'UNLINK' actions, as the 'CFUNCTION' alternative seems
to crash my 'devfsd'.
I have appended the relevant bit of configuration. As you may note I
have had to use the full Linus-style path to my CD-ROM and tape
drives, as these are constant, while as noted above the 'cdroms/' and
'tapes/' entries seem to be changeable, which makes them nearly
useless.
* In any case I usually dislike symbolic links, for various practical
and philosophical reasons; it would be nice if the 'MK{OLD,NEW}COMPAT'
actions could optionally make hard links instead of symbolic links...
This would also help in getting OLDCOMPAT or NEWCOMPAT names in
'/proc/mounts' and other places instead of the very verbose kernel
names.
It seems to me that hard links should be really very easy to add; I
just had a look at 'fs/devfs/base.c' and this seems indeed the
case. Any subtle reasons why such a typical UNIX thingie is not
supported?
* It might be rather useful if 'devfs', whether or not was mounted as
'/dev' or not, always mounted itself as '/proc/dev', as this would be
both logically appropriate and easy to rely upon.
* It would be nice if you kept a page (or may I could) with a list of
applications that are use the old names, and possible workarounds.
For example some versions of 'rxvt' has '/dev/ptyXX' hardcoded in, but
some don't, and the rather equivalent 'aterm' uses '/dev/pts', so it
is fine. 'diald' uses '/dev/pty%d' too, but not really, so it's fine.
Also, it is possible to list the configuration bits that need to be
changed to 'devfs'-ify them, and tips and tricks on figuring out which
old-style entries one needs, e.g. using 'fuser -M /dev' or 'lsof +d
/dev' or 'lsof +D /dev | sort -t/ +1a'.
devfsd.conf
Description: Binary data
devfsd.local
Description: Binary data
|