From owner-freebsd-arch Tue Feb 20 14:19:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id CCBD337B684 for ; Tue, 20 Feb 2001 14:19:14 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id PAA79236; Tue, 20 Feb 2001 15:18:47 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp10.phx.gblx.net, id smtpdMN7pMa; Tue Feb 20 15:18:39 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id PAA28977; Tue, 20 Feb 2001 15:19:04 -0700 (MST) From: Terry Lambert Message-Id: <200102202219.PAA28977@usr05.primenet.com> Subject: Re: modifying config files for a running daemon To: rjesup@wgate.com Date: Tue, 20 Feb 2001 22:18:59 +0000 (GMT) Cc: jonathan@graehl.org (Jonathan Graehl), freebsd-arch@FreeBSD.ORG In-Reply-To: from "Randell Jesup" at Feb 20, 2001 04:13:03 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > At the moment, I don't think so, since there's no change > notification. Certainly it wouldn't be tough to create a protocol/API that > provided that functionality, at least if you can guarantee that the writer > uses the protocol, or by use of a special pseudo-fs, etc. Since a > change-notification protocol/API would need to be defined anyways, there > wouldn't be a problem including this. I believe that the support for file > notification in the Amiga ramdisk notified on close of a modified file > (I've lost too many neurons to be sure). > > Providing it on an arbitrary FS _without_ requiring the writer to > use the defined protocol would be quite a hairy change to make, of course. Actually, it's pretty trivial; it's one area where a stacking layer wouldn't need it's own vnodes in order to stack. You could do it by building a pseudo-vector instance for each mount when you were creating the VFS instance. The pseudo-vector would catch the event, and then call the real vector. You couldn't just tag the system calls, since write faults as a result of mmap() don't go through the system call path. Adding the code to vfs_init() would be pretty trivial. While you were there, sorting the decriptos in the vector list would let them be referenced directly by offset, and remove a level of indirection for each layer transition, making the overall use of the VFS framework less expensive. On a general note... This is one of the (many) obvious places where the object contents are not rearranged by a stacking layer, so the layer implementing it doesn't need a vnode/vmobject_t association. If we could rip that assumption out of the VFS, almost all of our cache coherency issues would magically disappear. The only places they wouldn't would be in translation layers (compression, encryption, name space conversion, character set conversion, etc.), where the view in user space of the object isn't the same as the view in the backing store. This is really a tiny fraction of the problem space VFS' are capable of mapping. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message