On Thu, 13 May 2010 13:04:18 +0530 "Aneesh Kumar K. V" <aneesh.kumar@xxxxxxxxxxxxxxxxxx> wrote: > On Thu, 13 May 2010 16:56:06 +1000, Neil Brown <neilb@xxxxxxx> wrote: > > On Thu, 13 May 2010 11:55:56 +0530 > > "Aneesh Kumar K. V" <aneesh.kumar@xxxxxxxxxxxxxxxxxx> wrote: > > > > > On Thu, 13 May 2010 11:43:51 +1000, Neil Brown <neilb@xxxxxxx> wrote: > > > > On Wed, 12 May 2010 21:20:40 +0530 > > > > "Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > > This enables to use open-by-handle and then get the link target > > > > > details of a symlink using the fd returned by handle > > > > > > > > > > > > > > > > > I find it very frustrating that a new syscall seems to be needed here. > > > > We have 'readlinkat', and it should be enough. > > > > How: the 'dfd' has to be a 'directory', and the path name as to be non-empty. > > > > > > > > The following patch allows 'path' to be NULL and in that case 'dfd' to be a > > > > non-directory. This allows readlinkat and faccessat (and probably others) > > > > to be used on an fd with not following path name. > > > > > > > > What do people think of this alternative? > > > > > > > > > > I will add this in the next iteration and drop the freadlink syscall. > > > > > > > I wouldn't be quite that hasty. It was only a proposal. It might not be > > appropriate to change all those syscalls.. > > > > An alternative that I don't think is a nice, but is a lot 'safer' is > > to just change readlinkat to accept a NULL path: > > That would mean only readlinkat now have a special case of accepting NULL path > and dirfd can point to objects other than directory. So from the > interface point of having the special case is confusing. But if you feel > strong enough to drop freadlink syscall i can do that. Just not sure > whether special case for only readlinkat is the right way considering we > have fstat/fchwon type calls for other file system operations. > > Not completely a special case. I modelled this code on utimesat. NeilBrown -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html