Date: Wed, 28 Jul 1999 16:31:04 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: "David E. Cross" <crossd@cs.rpi.edu> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: userfs help needed. Message-ID: <199907282331.QAA64309@apollo.backplane.com> References: <199907282307.TAA94518@cs.rpi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
:I am wading through the portalfs and nullfs source, but I am desperately :lost. I would love to be able to find out who would be willing to help out :with questions. I feel I would be spamming far too many people by just sending :to -hackers. Some of the topics I am curious about are general fs-style :questions, what the various vop/vfs calls do. Also I would like to know how :to setup a shared memory segment between kernel and user space (as matt :dillon suggested). Finally I would like to know how the buffer-cache interacts :with the filesystem layer. : :Thanks :-- :David Cross | email: crossd@cs.rpi.edu :Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Ouch. I don't think anyone understands the VOP stuff completely. It's a big mess -- which is why it's going to be rewritten later this year. Your best bet is to study the implementation of the UFS/FFS filesystem. It may also help to study a more recent filesystem such as coda. Specifically, ufs/ufs/ufs_vfsops.c ufs/ufs/ufs_vnops.c ufs/ffs/ffs_vfsops.c ufs/ffs/ffs_vnops.c coda/coda_vfsops.c coda/coda_vnops.c What I recommend is that you implement a skeleton that essentially returns an error for all the call entries and does a kernel printf(), and then implement the routines one at a time. The various VOP calls have different locking requirements and resource freeing requirements. The most difficult resource to deal with in the entire subsystem is the struct componentname structure used for lookup and related ops - all related to namei. That is, the code that deals with path elements. Generally speaking the VOP code is required to free a pathname component before returning, but not in all cases. It's a really odd set of rules and I'd have to review them myself to be able to explain them. -Matt Matthew Dillon <dillon@backplane.com> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907282331.QAA64309>