From owner-freebsd-arch Tue Feb 20 13:16:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 998A537B4EC for ; Tue, 20 Feb 2001 13:16:20 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id OAA15280; Tue, 20 Feb 2001 14:13:14 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpdAAAMNa4YD; Tue Feb 20 14:13:05 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id OAA27627; Tue, 20 Feb 2001 14:16:09 -0700 (MST) From: Terry Lambert Message-Id: <200102202116.OAA27627@usr05.primenet.com> Subject: Re: DJBDNS vs. BIND To: jlemon@flugsvamp.com (Jonathan Lemon) Date: Tue, 20 Feb 2001 21:16:09 +0000 (GMT) Cc: arch@freebsd.org In-Reply-To: <20010220105723.C85542@prism.flugsvamp.com> from "Jonathan Lemon" at Feb 20, 2001 10:57:23 AM 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 > It would be fairly trivial to monitor a configuration file with kevent, > which would generate a notice whenever the file is changed/copied/renamed, > etc. I believe that John-Mark Gurney had patches somewhere to implement > exactly this for inetd. > > The problem is that under our current model, the administrators do not > expect writes to the file to take immediate effect, and this immediately > breaks POLA. So while it could be done, it may not be a good idea. At > the very least, I would argue that it should be hidden behind a flag option. This is what makes something with an API a better bet, since you can define it to be a semantic of the API. That prevents a POLA violation. I like that people are willing to at least discuss using a new API that isn't implemented everywhere; many of the system calls we have today started out that way, too, and it was use, which proved their utility, which propelled them to the level of a standard. Lets not hamstring ourselves over having to hide such a fundamental improvement behind a flag, before we even know the shapes it might take. We'll have the rest of time to be self limiting, after we figure out what it should look like. 8-). 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