| 1 |
Ok, now that devfs is removed from the 2.6 kernel tree[1], I think it's |
| 2 |
time to start to revisit some of the /dev naming rules that we currently |
| 3 |
are living with[2]. |
| 4 |
|
| 5 |
To start with, the 061 version of udev offers a big memory savings if |
| 6 |
you use the "default" kernel name of a device[3]. If you do that, it does |
| 7 |
not create a file in its database in /dev/.udevdb/ |
| 8 |
|
| 9 |
If we can move away from some of our devfs-like names, we stand to |
| 10 |
reclaim a lot of memory from everyone's machines. As an example, if we |
| 11 |
drop all of the tty/pts/vc/vcc symlinks, and just go with the default |
| 12 |
kernel name, we save 2.5Mb of space in tempfs/ramfs. I've done this on |
| 13 |
my machines and everything seems to work just fine (it looks like |
| 14 |
everything that was trying to use a tty node was just using the symlink |
| 15 |
anyway.) |
| 16 |
|
| 17 |
So, anyone have any objections to me changing the default udev naming |
| 18 |
scheme in this manner? |
| 19 |
|
| 20 |
Next up, that loony block device naming scheme (more on that later...) |
| 21 |
|
| 22 |
thanks, |
| 23 |
|
| 24 |
greg k-h |
| 25 |
|
| 26 |
[1] Yes, 2.6.13-rc1 does not offer devfs as a kernel option anymore, but |
| 27 |
the code is still present if you know how to enable the option and |
| 28 |
rebuild your kernel with it. I'll be working on killing it for good |
| 29 |
by, at the latest, 2.6.14. |
| 30 |
|
| 31 |
[2] devfs vs. udev flames will dutifully be ignored. Give up, it will do |
| 32 |
You no good to argue. |
| 33 |
|
| 34 |
[3] HAL needs a patch to be able to handle this. It's posted on the |
| 35 |
hal development mailing lists and will be checked in real-soon-now. |
| 36 |
-- |
| 37 |
gentoo-dev@g.o mailing list |
Archives