Yep, that's fixed in devfs-patch-v88 (there was briefly a bad version
on the ftp site but that was fixed several hours ago).
> But i had another problem i didn't see before:
> - i autoload cdrom and sr_mod modules trough kmod/modprobe
Do you mean you actually mean you load the modules, or just that you
have configured your system to support autoloading?
> - modprobe hangs during a "mount -av -t nonfs,nproc" which is called
> from a multiuser startup script while trying to autoload both
> modules; this doesn't happen without devfs!?
This is odd. I'm pretty sure this has been tested before. Have you
incorporated the sample modules.conf file I pointed out?
> There are two "solutions":
> - if i hack a workaround into the multiuser startup script doing
> a "modprobe sr_mod" before the "mount -av -t nonfs,nproc" it works
> with devfs.
> - or if i delete the cdrom entries in /etc/fstab --> o.k. with devfs.
> That sounds trivial but the amazing part of it is to insert them again
> after reaching multiuser and mount works!?
Neither are "solutions" in my book. They are temporary workarounds.
> Can this be a devfs race?
Probably not a race but some other problem. Have you tried inserting
strategic printk()s in the code, or enabling devfs debugging? With
devfs debugging, it can be a bit verbose (depending on which options
you select), but it makes it easy to trace many problems.
> Another issue (extension request):
>
> devfs_mk_compat() creates a devfs entry with devfs_register
> in case of _no_ compatibility symlinks boot option.
>
> But this entry is not associated to the "original" entry.
> For egg. /dev/sr0 associated to /dev/sr/c2b0t0u0.
>
> If they where associated to each other a devfs_unregister()
> of the diretory /dev/sr/ would be able to unregister any compatibility
> entries too.
>
> What do you think about an additional member in the
> devfs_entry structure holding the link in the "compatible"
> entry (/dev/sr0) pointing to the "original" one (/dev/sr/c2b0t0u0) to
> implement this? This would not break the n:1 relationship between
> compatible entries and original ones.
>
> devfs_unregister() would then be able (in addition to the entries
> below the directory beeing unregistered) to unregister the
> compatible entries too.
Actually, I'm glad you raised this. In fact, the mechanism is already
there: see <devfs_set_symlink_destination>. All I need to do is make
use of it. I'll just change the interface to <devfs_mk_compat> to take
a handle to the "real" devfs entry. I could put out a new patch for
this... But:
The reason I'm glad is because I've been considering removing that
functionality. It's only used in the tty driver, and there it is easy
enough to keep track of both entries and unregister as needed. In my
considerations I figured that any driver that is registering a "real"
entry and a symlink can easily keep track of both entries.
If you have found a case where it is too hard for a driver to keep
track of both, then I'd like know more about it. So could you explain
what is happening some more? Offhand, I don't see why there is a
problem for the driver keeping track of two entries.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/