It took me almost the whole weekend to find out why devfsd does not try
to load module to access Jaz drive. Then I realized that I already had
link /dev/sda4 -> /dev/scsi/bla/bla/bla. I.e. no LOOKUP event was
triggered and devfsd did not load any module. I tried to removed link
from /dev, remove it from /lib/dev-state, reboot, attached Jaz, mounted
it - module was automagically loaded and lo and behold - I again had
/lib/dev-state/sda* links and of course after next reboot no module was
loaded again.
Well, it took me sometime to uderstand it was devfsd itself reposnsible.
What happened was
- module was loaded and registered "canonical" names
- devfsd received REGISTER event and created compatibility devices (links)
- this in turn triggered CREATE event from devfs
- and devfsd copied newly created link into /lib/dev-state
Now comes our rc.sysinit that copies /lib/dev-state back on startup ...
and no module is ever loaded when you try to access devices.
This is very nasty situation. I do not see any real workaround except
removing this "restore from hardcopy". Then we get back the same problem
with /dev/modem & Co.
One workaround is to *not* copy entries that are managed by devfsd
itself (OLD- and NEWCOMPAT). That means, rc.sysinit should not copy
these entries back (they may still exist
due to permissions change). In this case rc.sysinit should obviously be
kept in sync with devfsd code. It may even be automated (extraction of
these names out of devfsd sources). I.e. something like
cd /lib/dev-state
find . \( -name sda\* -o -name ide -o -name ... \) -prune -o -print |
cpio -pmdu /dev
the problem is this list in braces :-)
More radical is to not use old names. Using /dev/discs/* e.g avoids the
problem. But I guess it is too late now (espicially if we want to
aintain compatibility with non-devfs case)
This may be considered devfsd bug ... but to fix it means major design
change. And we must do something for 8.1.
-andrej
-andrej
