Date: Tue, 20 Feb 2001 21:10:27 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: rjesup@wgate.com Cc: arch@freebsd.org Subject: Re: DJBDNS vs. BIND Message-ID: <200102202110.OAA27450@usr05.primenet.com> In-Reply-To: <ybupugd2u4n.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> from "Randell Jesup" at Feb 20, 2001 11:31:52 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> There's still a synchronization problem, even if the hostname > is in shared memory, even if the write is atomic (a reader may be in the > middle of reading the string). The easiest way to deal with this is to put the access behind an API, to guarantee atomicity. But there is a better way. > Fetching the data out of a kernel service on each access would be > (potentially) a pretty major hit, performance-wise. Some form of > registration of interest in the data would be better. Either something > like the Amiga (get a signal/message/callback/whatever when it changes, > then request the new information), or something that passes the > notification along with the new data. The approach I was thinking of would be to map the pages with the data in them read/write in kernel space, and read-only in all user space programs. The updates could be atomic by way of page replacement, which avoids the "middle of the string" problem. Pages are replaced prior to swap in on the next quantum (late binding). Writes would be by way of a system call API. The obvious one to use is "sysctl". Normal use would mean that this was zero overhead, which is better than getting the data from a file, anyway. Getting back to the system, group, and user logical naming, you could actually push the environment into the kernel; this would break direct references to "environ" (very old code), which is no loss, but it would potentially complicate the heck out of execve(), unless it were done right (stupid POSIX...). 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?200102202110.OAA27450>