svn commit: r206560 - head/sys/fs/devfs

Kostik Belousov kostikbel at gmail.com
Thu Apr 15 13:26:34 UTC 2010


On Thu, Apr 15, 2010 at 04:01:56PM +0300, Jaakko Heinonen wrote:
> On 2010-04-14, Kostik Belousov wrote:
> > First, I think we shall sort dirent->dd_dlist so that symlinks are
> > located before any other entries, and allow for duplication of
> > any name with the name of symlink.
> 
> What will happen when user deletes a symlink covering a device?
> Uncovering the device may a bit surprising? If user created directories
> will be allowed one day, they will face the same problem.
Yes, device will be uncovered if it is there, the same with the
directory.

Use case I have in mind when I wrote this is the following:
assume we have devices named dev1 and dev2, and two jails, j1 and j2,
each with its own devfs mount.
Also, assume that some program A has hardcoded /dev/dev1 as the name of
device to operate, and it is run both in j1 and j2. Further, j1 is given
access to /dev/dev1 only, while j2 is given access to /dev/dev2 only.
Then administrator of j1 can create a symlink /dev/dev -> dev1, while
administrator of j2 symlinks /dev/dev ->dev2, and both j1 and j2 would
operate properly.

This is not that perversed as it sounds, I think it is an essence of
symlink usage on devfs.
> 
> > I remember there was a PR to change devfs_symlink() so that symlink is
> > added to dd_dlist into head, not to a tail, as it is done now.
> 
> kern/114057
> 
> > Assume that all full devfs pathes except symlinks are stored somewhere
> > with type information for the component at the end.
> > Then, just iterating this set at make_dev() time, we can verify that
> > name is not a duplicate, and that the path components are not already
> > used as device name (only as directories).
> > The pathes storage need to be protected by dev_mtx. 
> > 
> > Possibly, the cdev_priv.c_dev.__si_namebuf may be reused at the
> > cost of long check at the make_dev() time.
> 
> Could you elaborate on this? I am not sure if I understand what you mean
> with __si_namebuf reuse.
I mean that we do not to create the structure that mirrors the directory/nodes
hierarchy for devfs dirents, but can dynamically parse __si_namebuf at
the make_dev() time, iterating over all nodes using cdevp_list.

For symlinks, it seems the easiest route is to have separate ref-counted
structures containing the pathes for owning directories.
> 
> > What do you think of this ?
> 
> I don't see anything obviously wrong with it.
> 
> -- 
> Jaakko
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-all/attachments/20100415/3cb40231/attachment.pgp


More information about the svn-src-all mailing list