Getting Ready for devfs
The most obvious change in Linux 2.4 is devfs.
Important! You must have devfsd installed, before booting Linux 2.4, or Linux will be unable to find your root partition.
If you Linux distro is Linux 2.4-ready, it will include the devfsd package right where you got your distro. If not, check around to see if you can find the pacakge.
Simply installing the devfsd package, should get it up and running, at least well enough to boot Linux 2.4, and use many of it's functions. This guide will get into fine tunning, later on.
What is devfsd
devfsd is a daemon, which provides control over the device filesystem. It allows the user to choose permissions (instead of the default) in /dev, it links obsolete devices to there new devfs counterparts, and generates new devices as neccessary.
What is devfs
devfs is short for "Device Filesystem", a virtual filesystem, similar to /proc. devfs replaces the traditional /dev, with a dynamically generated, organized structure. It also only shows devices that really exist on your system -- not every possible device, like Linux 2.2's /dev did.
The New Organization System
This new organization of /dev items breaks some apps. So as an compatibility layer, devfsd remaps old /dev entries that your apps are looking for, to new ones. You will notice that the old devices, linked to the new ones, are there, if any app requests them.
For example:
aarthur@cowsandcorn:~$ ls -l /dev/mixer lr-xr-xr-x 1 root root 11 Oct 21 18:27 /dev/mixer -> sound/mixer
Neat, huh? devfs moved the mixer device, into a sensible place, the /dev/sound directory. And if you check in that directory, you will see only the devices that actually exist will live there:
aarthur@cowsandcorn:/dev/sound$ ls dsp mixer unknown6
unknown6, apparently is the device that supplies info on your sound card. This will probably be fixed in the near future, so don't expect it to be named unknown6 forever.
If you had previously used the New Input Layer, then the input directory in /dev is not completely different to you. It contains many of the same the character devices for USB and ADB Input devices, but only the ones that exist on your system. You may see multiple mouse devices, this is due to multiple addresses on your mouse (for multiple buttons, etc). Always just use /dev/input/mice (a mixed input of all the mouse devices), when asked for the mouse device.
MAKEDEV, Symlinks, Changing Permissions
As /devfs is a virtual filesystem, any changes made to it, will not be preserved after reboot. That means any apps that directly modify the properities of /dev are useless, unless you are only interested in preserving settings between reboots.
This means, you can forget using ./MAKEDEV, chmod, chgrp, etc. with devfs. Instead, you should edit devfs' config files, found in /etc/devfs.
Setting Permissions
Most likely, a permission in /dev won't be what you want. To change the permissions of a device in the past, you could simply use chmod, chgrp and chown.
These methods will still work with devfs, however these changes won't be kept between reboots.
To keep changes between reboots, you must edit /etc/devfs/perms.
Example Part of the Perms file:
REGISTER ^adbmouse PERMISSIONS root.root 0660 REGISTER ^agpart[^/]* PERMISSIONS root.video 0660
Every device starts out with the word REGISTER, this tells devfsd to create this device upon boot.
The device name is second. To find the device you are looking for, use the find feature in your text editior.
The wildcards, and symbols in the device names may seem strange to you. A carrot -- ^, infront of a device represents any path to it -- such as /dev or /dev/input. The [^/]# after a name, means that it sets the permission on the folder the device is in.
The second part of the line sets permissions. This is the part you most likely want to change.
The part before the dot, is the owner. In most cases, you will want this to be root.
Right after the dot, is the group. Often distros name the group after the feature it provides -- and the system admin, is suppost to add users to that group, to gain proper access to that device.
Last on the line is the numeric permissions. Here is a quick review, incase you have forgotten them:
- First Number = SUID/GUID, etc.
- Second Number = Owners Permissions
- Third Number = Group Members Permissions
- Fourth Number = Everybodys Permissions
- 0 = No Permission
- 1 = Exec Permission -- Rare on Devices
- 2 = Read Permission
- 4 = Write Permission
- Permissions can be added, such as rwx = 7
Compatibility Links
When running devfs, anything that is not a directory, excluding 'null', 'mem', 'xconsole' and possibly a few others, is a symlink to the real device -- only there for compatibility reasons.
You will probably find that you will want a link to some other 'real' device in the near future. For example, if you are using Xpmac (with USB support) you will need a link pointing from /dev/usbmouse to /dev/input/mice.
To do this, open up (as root) /etc/devfs/symlinks in your favorite text editior.
You can then proceed to edit it to your liking, if you are using Xpmac, you need to add this line:
input/mice usbmouse
Adding New Devices
devfs should create every device, your kernel supports. If for some reason it fails, you can edit /etc/devfs/devices. You probably can skip over this section, but it is nice to know about.
A sample devices file would look like:
# format: name [bc] major minor uid gid mode bogus 1 3 0 0 0700
If you don't have a clue what the minor or major numbers are for the device you are trying to add, then you can't add it. The old MAKEDEV script might be of help to you.
Another good source for info on devfs is /usr/src/linux/Documentation/filesystems/devfs. Take a look in there if you have more questions.
Send comments to . Thanks.
