I ran screaming into the woods last year from trying to grok VOP_foo. The prospect of a rewrite fills me with warmth and fuzziness. I hereby volunteer to maintain the VOP(9) man pages and to flesh out my notes into a big, beefy FS-implementer's Guide to the new VOP_foo. All the coders have to do is answer my (at least marginally clueful) questions along the way and keep posted as to what's going on in new VM-land. I won't even pester anyone with design suggestions... very much. Solid offer, kids. Everybody wins. Give it some thought.
> -----Original Message----- > From: Matthew Dillon [SMTP:dil...@apollo.backplane.com] > Sent: Wednesday, July 28, 1999 6:31 PM > To: David E. Cross > Cc: freebsd-hackers@FreeBSD.ORG > Subject: Re: userfs help needed. > > :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: cro...@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 > <dil...@backplane.com> > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
