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:[EMAIL PROTECTED]]
> Sent: Wednesday, July 28, 1999 6:31 PM
> To: David E. Cross
> Cc: [EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
> :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
> <[EMAIL PROTECTED]>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
