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

Kostik Belousov kostikbel at gmail.com
Wed Apr 14 15:42:53 UTC 2010


On Wed, Apr 14, 2010 at 05:20:00PM +0300, Jaakko Heinonen wrote:
> On 2010-04-14, Kostik Belousov wrote:
> > > Otherwise sounds reasonable suggestion. However changes are needed in
> > > devfs. Currently devfs_populate_loop() is not along the make_dev*()
> > > code path but make_dev(9) increases a generation counter and
> > > devfs_populate_loop() gets called sometimes later. To make things more
> > > complex there may be several devfs mounts with different symlinks (files).
> > Right, my point of my suggestion was to not modify populate_loop() at all.
> 
> How you would detect an attempt to create a duplicate file then? Please
> note that there may be directories and user created symbolic links. The
> file set may be different on different devfs mounts.

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. 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. The change itself
is not enough, but together with other parts of this it might
be ok.

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. The symlink creation
shall also put the path of its containing directory into the store.

What do you think of this ?
-------------- 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/20100414/4a8293e0/attachment.pgp


More information about the svn-src-all mailing list