Re: test of devfs patch v88 [was Re: devfs patch v84 for linux-2.2.0-pre9 bugfix]
Richard Gooch (rgooch@atnf.csiro.au)
Tue, 26 Jan 1999 18:01:30 +1100
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/