Date: Tue, 8 Nov 2005 16:47:46 -0800 From: "Devon H. O'Dell" <dodell@ixsystems.com> To: fs@FreeBSD.org Cc: freebsd-emulation@FreeBSD.org Subject: Questions on VFS and linux emulation Message-ID: <20051108164746.A42559@knight.ixsystems.net>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051108164746.A42559>