Edit the start script, append your commands to create the links.
Or edit the correct file in /etc/udev/rules.d to include the links.
If you wire your devices to a named/numbered port, you can use one device
node for each port. Therefore it's sane to create hda to hdd, fd0 to fd3,
etc. But if you don't have a fixed mapping (USB), or if you'd have too
many possible (and mostly unused) ports for the available amount of devices
(SCSI), you can not create fixed numbers. Even for hde ..., you have no
native ordering, you can only tell the first controller from the rest.
When the SCSI naming was created, there were at most 256 SCSI devices of
each kind. Since each partition is a SCSI device, too, you had at most
16 disks of up to 15 partitions! This was later extended to 128 disks.
If you'd hardcode the controller, linux would have been unable to support
more than 8 SCSI controllers.
The result was the semi-random enumeration of the SCSI devices, and all
the hacks trying to work around that. (google for Joerg Schilling lkml)
Udev provides a clean way of naming the devices, using the static
information from the devices or the path.
I agree that the current udev documentation makes it hard to even find the
settings you'd like to change. That's because the documentation is meant
for developers, while the configuration is themed by the distribution.
The udev files itself are as simple as possible. Imagine them to be
<bloat>XML</bloat>, like the pile of HAL, DBUS and KDE automatically
mounting my disks using the wrong settings into the wrong directory
and forcing me to su in order to umount them! I temporarily beat that
beast, but the kill is still on the TODO list. Maybe as soon as I find
more^W usable^W documentation ...
You aren't stopped from directly poking the memory and crashing the systems
either - if you are root. Or from deleting all nodes on a classic /dev.
Don't do that then.
No system can load modules that are not on initrd, and only needed-for-boot
modules are usually put on the initrd. The bulk of modules must be loaded
from the real root. This seems to work quite well (except not here because
I prefer to include all necessary drivers in the kernel.)
I've debugged hotplug, too, and I found it was a wrapper around a wrapper
around ... a script that would be supposed to load the required firmware,
except it did neither load it nor provide a way to find out why it didn't.
Each HOWTO mentioned a different directory to use, and a different filename.
I'd have settled for manually loading the firmware, but hacking the scripts
to pieces was finally easier than finding out how I was supposed to do that.
I did not need to install a firmware after this, therefore I don't know if
udev is better, but it CAN'T be worse.
--
