Messages in this thread | | | Date | Tue, 26 Jan 1999 18:01:30 +1100 | From | Richard Gooch <> | Subject | Re: test of devfs patch v88 [was Re: devfs patch v84 for linux-2.2.0-pre9 bugfix] |
| |
Heinz Mauelshagen writes: > > > 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: > > Great. > > > 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.
Yes, but the driver doesn't know if the /dev/sr0 entry it is registering is a symlink or a real inode. In the case where it's a real inode, the driver has to unregister the entries anyway. So the code has to be there, one way or another.
Now, I could still add the code to <devfs_mk_compat> to call <devfs_set_symlink_destination>, but it just introduces an asymmetry, and doesn't seem to provide any real gains, because *you have to have code to unregister all the compatibility devices anyway*.
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/
| |