From owner-freebsd-arch@FreeBSD.ORG Thu Apr 19 10:35:56 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B82AB16A400; Thu, 19 Apr 2007 10:35:56 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 91C3313C455; Thu, 19 Apr 2007 10:35:56 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 0107647299; Thu, 19 Apr 2007 06:35:56 -0400 (EDT) Date: Thu, 19 Apr 2007 11:35:55 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Diomidis Spinellis In-Reply-To: <20070419101815.Y2913@fledge.watson.org> Message-ID: <20070419113528.X2913@fledge.watson.org> References: <461958CC.4040804@aueb.gr> <20070414170218.M76326@fledge.watson.org> <4621E826.6050306@aueb.gr> <20070415105157.J84174@fledge.watson.org> <46231C64.9010707@aueb.gr> <20070419101815.Y2913@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, re@FreeBSD.org Subject: Re: Accounting changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 10:35:56 -0000 On Thu, 19 Apr 2007, Robert Watson wrote: > If we're willing to assume architectures can only read their own accounting > files (the status quo), the above argument doesn't really make sense. You > end up with a series of versions of "struct acct", and that code is > architecture-neutral. Thinking about it more, I'm not sure a per file > header is even required or desired (as I had previously suggested), simply a > per-record versioning scheme, allowing a reboot onto a new kernel to > continue to write to the existing accounting data. Read the first 16 bytes, > if the first byte is non-0 then it's the original "struct acct" layout, and > otherwise the second byte is the version number to use. Or in the interests > of forward compatibility, include a length parameter in another 16 bytes so > you can skip over records if necessary in order to allow the kernel to move > back and forward across file versions if there's a problem after the > upgrade. s/16 bytes/16 bits/ was intended in the above. :-) Robert N M Watson Computer Laboratory University of Cambridge