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
pgpctzhUaU8zL.pgp
Description: PGP signature
