Re: semantics of TRYEMULROOT

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Sun, 2 Jan 2011, David Holland wrote:

[...]
> 
>    char last[NAME_MAX];
>    namei_parent(path, &dvp, last, sizeof(last));
>    vn_lock(dvp);
>    VOP_MKDIR(dvp, last);
>    vn_unlock(dvp);
>    vrele(dvp);
> 
> which is simpler and a lot tidier, both on the surface and inside the
> fs; however, if TRYEMULROOT is wanted it's obviously not desirable to
> need a retry loop here (and in each of the several other similar
> functions) -- therefore I'd like namei_parent to be able to commit to
> a (parent) directory to operate in, handling TRYEMULROOT inside itself
> only. In addition to fitting my design better I think this provides a
> more consistent semantics; I just want to make sure we think it'll
> work before committing to it.

TRYEMULROOT should only open existing objects on the emul path, it should 
never create anything new, so you would never want to use it for mkdir.  
I don't know if that means you need to pass an extra flag to 
namei_parent() or what.

Eduardo