Will fetch the good version.
> > 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?
System is configured for 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.
Will try this and debugging too and get back to you.
> > 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.
Yes, you are right if there are only two entries to keep track of.
> 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.
No, i don't have one at this point in time, but was thinking about
a nice kind of "one for all" service devfs could do for each driver.
This would avoid to do (lots) of devfs_unregister() calls
in each driver _and_ to hold the entry data for all of them.
The idea has been born while having a look at some of the devfs driver
patches (for egg. in sd.c), where you create a directory /dev/sd/
which in turn could have lots of subdirectories (it doesn't in sd.c devfs
use, but it could as an example).
The actual scsi disk scenario of up to 128 disks with up to 16 partitions each
;*) causes the registration of up to 2048 specials in the directories.
The current implementation removes _all_ the entries (>2048 in my example)
including the top one with _one_ devfs_unregister() call given _one_
devfs_handle of the top level entry /dev/sd/.
Only that _one_ devfs_handle has to be stored and handled by the driver.
But in addition to this the example implies 2048 compatibility nodes to.
If the recursive delete in devfs_unregister would include the
compatibility links too, 2048 devfs_unregister in the driver could be avoided.
Systemmanagement Entwicklungsbereich 2 Deutsche Telekom AG Entwicklungszentrum Darmstadt Heinz Mauelshagen Otto-Roehm-Strasse 71c Postfach 10 05 41 firstname.lastname@example.org 64205 Darmstadt Germany +49 6151 886-425 FAX-386 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com Please read the FAQ at http://www.tux.org/lkml/