Date: 05 Mar 2001 18:41:39 -0500 From: Randell Jesup <rjesup@wgate.com> To: Wes Peters <wes@softweyr.com> Cc: Randell Jesup <rjesup@wgate.com>, Terry Lambert <tlambert@primenet.com>, Matt Dillon <dillon@earth.backplane.com>, Alfred Perlstein <bright@wintelcom.net>, josb@cncdsl.com, chat@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <ybug0gr3hsc.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> In-Reply-To: Wes Peters's message of "Tue, 20 Feb 2001 21:33:11 -0700" References: <200102200122.SAA04466@usr05.primenet.com> <ybupugd2u4n.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> <3A934507.A0645CF3@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Moved from -arch to -chat.
Wes Peters <wes@softweyr.com> writes:
>Randell Jesup wrote:
>> As an aside, we ran into this in AmigaDos as well. We cached all
>> of our preferences (configuration) data in ramdisk files (which hardly took
>> any space, since there was no block overhead, and guaranteed fast access).
>> I then added notification commands to the filesystem, so applications could
>> find out when the configuration changed. For fixed-size (binary) config
>> files, you could simply make a single read, which became a ram-to-ram copy
>> without very much overhead. For variable-sized files, a simple exclusive
>> open and then read would do. Since these were all ram-to-ram copies, and
>> the overhead on the Amiga of message passing and Open()/Read() was small,
>> it worked well.
>>
>> >A registry-like configuration store, which was cached by the OS,
>> >and was referenced directly each time the data was needed, instead
>> >of allowing the programs to cache data which might change would
>> >really be the best approach,
>>
>> 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 downside is that to change the data, you must also go through
>> this procedure. The nice thing about the Amiga notification method was
>> that you could use any tool to modify a preference (configuration option) -
>> text editors, fancy GUI editors, copy (cp), etc. You could still provide
>> this behavior if you made this configuration cache also act as a virtual
>> FS, so you could call up (say) /config/hostname into vi, change it, then
>> just save it. Or just copy another file over the existing one, etc. This
>> kindof turns vipw on it's head.
>>
>> An alternative would be to leave everything in normal files,
>> extend the vipw schema to lock arbitrary files (configedit), and then hook
>> it into a notification method as per above. This loses the ability to use
>> something like cp, but it allows arbitrary text editors, and hooks can be
>> given to allow GUI programs to interact with a config file as well.
>>
>We in the unix world have a well-founded aversion to storing configuration
>information in binary data stores that can't be accessed via ed(1) when
>the system is in single-user mode. If we wanted to stuff all the system
>configuration into such a black hole, we could've done it with DBM data-
>bases more than a decade ago, quite easily.
As someone said, vipw is a good counterexample.
The above schemes do allow you to use ED (if you like) to edit
configuration files. In one case it's totally free (even cp will work), in
the other you have to use some sort of vipw thing to invoke the editor and
make sure that the file is notified as changed (or integrate with the
editor in some automatic or semi-automatic way).
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
rjesup@wgate.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybug0gr3hsc.fsf>