From owner-freebsd-hackers Wed Jul 28 16:31:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id DEA1B1533B for ; Wed, 28 Jul 1999 16:31:06 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA64309; Wed, 28 Jul 1999 16:31:04 -0700 (PDT) (envelope-from dillon) Date: Wed, 28 Jul 1999 16:31:04 -0700 (PDT) From: Matthew Dillon Message-Id: <199907282331.QAA64309@apollo.backplane.com> To: "David E. Cross" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: userfs help needed. References: <199907282307.TAA94518@cs.rpi.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message