[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

devfsd changes

If you don't want to read all the gorey details skip down to "* * * * *".

Following bug report #111946 and a number of issues with devfs I have decided 
that some serious changes are necessary to the way permissions for devices 
are managed.

Here is the way it currently works:

When I (or an auto-builder) build a devfsd package it creates a default 
/etc/devfs/perms file which contains the permissions of every device node in 
the system and every device node which is likely to be created (ideally it 
should be every device node possible but new devices are always being added).
This file is currently created from the contents of /sbin/MAKEDEV by a 
complex script which translates mknod commands to permissions settings 
suitable for devfsd.
Incidentally this creates another potential problem, where different 
auto-builders may build against different versions of makedev and have 
different config files, but this isn't an issue I even considered before 
writing this message...

Now the output of this script refers to old-style names such as /dev/hda not 
the devfs names such as /dev/ide/host0/bus0/target0/lun0/disc (the devfs 
equivalent of /dev/hda), this is a problem because converting from the old 
names to the new names is not always possible (for example when you see 
/dev/sda you won't know which SCSI bus or LUN it is, different systems will 
therefore have different SCSI names for /dev/sda).  This is a minor problem, 
a bigger problem is that when you have two IDE hard drives and an IDE cd-rom 
you won't know which of hda, hdb, and hdc is the cdrom!

Now if everyone had sym-links for all devices this might still be managable 
(with a huge amount of pain and some support scripts to handle the case of 
IDE cd-rom vs IDE hard drive).  However not everyone has "REGISTER .* 
MKOLDCOMPAT" in their config files so many people don't have compatibility 
links for all devices (I prefer to have as few compatibility links as 
possible on my systems - it's a matter of preferance).  A further 
complicating factor is that the functionality of assigning permissions based 
on the compatibility names is a Debian-specific hack which the upstream 
author dislikes.  So moving between Debian and non-Debian systems will be 
painful if you rely on this.

Also due to the way the compatibility code works it is possible to have 
different permissions of a device after a restart of devfsd with no 
configuration changes having been made!!!  So for example you are happily 
playing music from your CD-ROM and you decide to install/upgrade/remove 
lvm-common or tpctl (or one of the other packages that have devfsd 
configuration) and it will restart devfsd to read the configuration for it's 
device nodes, this could cause device nodes to get different permissions than 
they had on boot and make your CD-ROM unreadable to your music program!!!

To solve this I have started developing the next version of the devfsd 
package in the following fashion:

* * * * *
Firstly I have taken the latest auto-generated permissions file as my 
starting point, from now on it will not be automatically generated and I will 
manually merge changes from /sbin/MAKEDEV periodically (or when I receive bug 
reports or notification from the makedev maintainer of significant new 

I am changing the default perms file to use the new devfs names instead of 
the compatibility names in cases where there have been problems reported, in 
cases where I anticipate future issues, and for devices that I have on my own 
systems and can easily test which I think need to be changed.

I would like to change it all to the new format, but this isn't going to be 
possible for some time.  So it will have to be a gradual process continuing 
after the release of woody.

Here are the choices that devfsd users have:

1)  Continue to use their old setup and say "n" when asked whether 
/etc/devfs/perms should be replaced (NB you have to change /etc/devfs/perms 
before the upgrade to be given the choice).  Then these changes will not 
affect you for better or for worse.

2)  Check the new version when I put it in unstable and send me email about 
any devices you posess and have a good knowledge of which are in the old 
format and should be in the new format.  Doing "ls -lR /dev" before and after 
the upgrade and checking for changes would be helpful (there will be changes, 
hopefully all will be desired).

3)  Put devfsd on hold until it's all over.  There are no serious bugs 
against devfsd at the moment and I don't expect to find any in the near 

I know this sucks very badly.  But at the moment I can't think of a better 
solution to this situation (I am open to suggestions).  It will be some time 
before I upload a package with the new changes, I will certainly wait until 
discussion on these lists has reached some sort of consensus.

PS  I have BCC'd this to the debian-user list to make people aware of what's 
going on, I didn't CC it because I think that any further discussion only 
belongs in private mail or on the debian-devel list.

http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page

Reply to: