On Sun, Jan 02, 2011 at 09:19:51PM +, Eduardo Horvath wrote:
> 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_paren
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; howeve
On Sun, Jan 02, 2011 at 10:48:03AM +, David Laight wrote:
> On Sun, Jan 02, 2011 at 09:17:11AM +, David Holland wrote:
> > Because we have at least one FS that may not want paths being looked
> > up to be split on '/', namely rump etfs, and arguably the most
> > important simplification
On Sun, Jan 02, 2011 at 06:14:57PM +, David Laight wrote:
> On Sun, Jan 02, 2011 at 09:52:31AM +, David Holland wrote:
> > Has anyone ever sat down and clearly worked out the desired semantics
> > for TRYEMULROOT? I've noted inconsistencies in the past, and because
> > in a number of wa
On Sun, Jan 02, 2011 at 07:24:33PM +, David Holland wrote:
>
> (Anyhow, like I wrote in that PR, the only real way forward for
> onionfs is to try to figure out a self-consistent model for the
> semantics. If as I suspect that turns out to be impossible, the right
> way forward is to kill onio
On Sun, Jan 02, 2011 at 09:19:30AM -0500, matthew sporleder wrote:
> > [TRYEMULROOT]
>
> Since it's on http://www.netbsd.org/~dholland/buglists/file.html , I'm
> sure you're aware of it, but would 41678 be solved?
>
> http://gnats.NetBSD.org/cgi-bin/query-pr-single.pl?number=41678
Doubtful
On Sun, Jan 02, 2011 at 09:52:31AM +, David Holland wrote:
> Has anyone ever sat down and clearly worked out the desired semantics
> for TRYEMULROOT? I've noted inconsistencies in the past, and because
> in a number of ways it's a special case of onionfs I'm somewhat
> concerned that there may
Hi,
I have a fix for kern/44310 at the end of my post but first some
commentary:
-static int bpf_movein(struct uio *, int, int,
+static int bpf_movein(struct uio *, int, uint64_t,
struct mbuf **, struct sockaddr *);
I change mtu type because the actual argu
On Sun, Jan 2, 2011 at 4:52 AM, David Holland wrote:
> Has anyone ever sat down and clearly worked out the desired semantics
> for TRYEMULROOT? I've noted inconsistencies in the past, and because
> in a number of ways it's a special case of onionfs I'm somewhat
> concerned that there may be cases
On Sun, Jan 02, 2011 at 09:17:11AM +, David Holland wrote:
> Because we have at least one FS that may not want paths being looked
> up to be split on '/', namely rump etfs, and arguably the most
> important simplification to VOP_LOOKUP is to make it handle one path
> component at a time, we nee
Has anyone ever sat down and clearly worked out the desired semantics
for TRYEMULROOT? I've noted inconsistencies in the past, and because
in a number of ways it's a special case of onionfs I'm somewhat
concerned that there may be cases where the proper or desired behavior
is unclear or ambiguous.
Because we have at least one FS that may not want paths being looked
up to be split on '/', namely rump etfs, and arguably the most
important simplification to VOP_LOOKUP is to make it handle one path
component at a time, we need a way for a FS to decide how much of a
path it wants to digest at onc
12 matches
Mail list logo
