final decision about *at syscalls

Kostik Belousov kostikbel at gmail.com
Wed Apr 16 17:58:38 UTC 2008


On Wed, Apr 16, 2008 at 06:52:12PM +0100, Robert Watson wrote:
> 
> On Wed, 16 Apr 2008, Alfred Perlstein wrote:
> 
> >>File descriptor proposal works like this:
> >>
> >>userland
> >>	openat(fd, path)
> >>kernel
> >>	NDINIT_AT(&vp, path, fd);
> >>	/* operate on vp */
> >>
> >>Vnode proposal works this way:
> >>
> >>userland
> >>	openat(fd, path)
> >>kernel
> >>	dvp = file_descriptor_to_vnode(fd);
> >>	NDINIT_AT(&vp, path, dvp);
> >>	/* operate on vp */
> >
> >My first impression is that passing fp to vp code is a layering
> >violation and bad news.  I need to think about it more.
> 
> NDINIT() is already aware of the file descriptor array because it uses that 
> to get the current working and root directories.  And what the *at() system 
> calls are effectively doing is substituting another directory for the 
> current working directory.  The exact expression of all this doesn't matter 
> all that much to me, but I think evaluating the file descriptor array for 
> directory stuff all in one place, rather than spread over the caller and 
> NDINIT(), is cleaner and avoids a lot of code everywhere.  Nothing says you 
> can't have:
> 
>      void
>      NDINIT(struct nameidata *ndp, u_long op, u_long flags,
>          enum uio_seg segflg, const char *namep, struct thread *td);
> 
>      void
>      NDINIT_AT(struct nameidata *ndp, u_long op, u_long flags,
>          enum uio_seg segflg, const char *namep, int fd, struct thread *td);
> 
>      NDINIT_DVP(struct nameidata *ndp, u_long op, u_long flags,
>          enum uio_seg segflg, const char *namep, struct vnode *vp,
>          struct thread *td);
> 
> However, I think I wouldn't want NDINIT_AT() to be a wrapper for 
> NDINIT_DVP(), because I'd like all that fdp following to occur together.

I already mailed the patch implementing all the above, modulo
s/_DVP/_ATVP/. I want to get the response from Pawel and others. If
positive, the patch is to be tested and committed.

I see no reason for heating the debate.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20080416/2bfb7396/attachment.pgp


More information about the freebsd-arch mailing list