Date: Tue, 20 Feb 2001 22:18:59 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: rjesup@wgate.com Cc: jonathan@graehl.org (Jonathan Graehl), freebsd-arch@FreeBSD.ORG Subject: Re: modifying config files for a running daemon Message-ID: <200102202219.PAA28977@usr05.primenet.com> In-Reply-To: <ybuelwt2h40.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> from "Randell Jesup" at Feb 20, 2001 04:13:03 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102202219.PAA28977>