Questions on VFS and linux emulation

[Devon H. O'Dell]

Hey all,

Sorry for the cross-post; I've got questions that fall both into the
categories of our Linux emulation stuff and VFS stuff.

I've been working on amd64/88249 and it has brought up a few questions on
VFS and linux emulation for me. There is a good bit of background on the
issue that I posted in the PR, but to briefly summarize:

The linux emulation point for the getdent / readdir syscalls passes 
cookies up the VFS stack.

The devfs filesystem doesn't initialize the cookie pointer nor the
ncookies data.

vfs_readdir requires the caller to have set up both the cookie pointer
and ncookies data if the pointer to ncookies is non-NULL.

``boom''

However, looking deeper into the cause of this issue, I've come up with
a couple of questions on how this stuff works:

1) What is the application of cookies in this context? From what I can
tell, our native syscalls make absolutely no use of them. Is there a
reason then that they're used in the linux wrappers and not in ours?

2) How are cookies supposed to work? The only place I saw them actually
being used with a purpose, NFS, seemed to imply that it relied on the
behavior that the value of the cookie only ever increases.

3) Is UFS the only filesystem that does anything with cookies if the
caller asks for them?

With regard to both emulation and VFS:

4) I looked into the reason that the majority of the Linux file 
operation procedures didn't wrap our own syscalls like many other
emulation procedures do. It seems that our own syscalls are also
wrappers for other procedures. There are no wrappers for e.g. getdents,
e.g. the copyout() happens in the getdirentries syscall, so it cannot
be wrapped for Linux emulation. I always get the data confused that's
copied in and out, so maybe this isn't a necessity, but would it be
beneficial to modify e.g. getdirentries to wrap vfs_getdirentries so
that other emulation layers could wrap that as well?

5) Is the Linux emulation code in linux_file.c:getdents_common() doing
something really silly? For a large part, it looks like our own
vfs_syscalls.c:getdirentries() code, except I think it is doing
something incorrect with regard to cookie handling. Since I'm still sort
of confused as to how the cookies are supposed to work and I am not sure
how to set up a test in which I can call readdir() on a filesystem that
actually makes use of the cookies to see if it's doing something kooky,
I really need some outside input on this. I ask this specifically
because I do have a patch that optimizes and further abstracts our
vfs_read_dirent procedure so it can be used in other filesystems, but
it doesn't seem to work in Linux emulation.

Architecturally, I have a couple questions as well.

Discussing the issue with scottl@ and phk@, it seems it would be
preferrential for us to use vfs_read_dirent as the backend for all
filesystem_readdir operations. As previously mentioned, I have a patch
that incorporates this into devfs, and this works fine (outside of
Linux emulation, that is). Will this sort of work tread on anybody's
toes who is working in this area? (I'm not a committer, so I'm sure I
will have to work with somebody on this anyway, but if there are
already things going on in this area, I'd like to keep deltas to a
minimum). This code only touches filesystem_readdir() functions 
(filesystem_vnops.c files) and vfs_subr.c.

Hope somebody's got an idea as to what I'm talking about :). Some of
those sentences got pretty long. It's an involved discussion, so I hope
that someone with more familiarity with this can give me some tips and
perhaps review what I do.

Please keep me cc'ed to this discussion as these two lists I'm actually
not subscribed to.

Kind regards,


Devon H. O'Dell
vfs_subr.c