Date: Thu, 19 Apr 2007 11:35:55 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Diomidis Spinellis <dds@aueb.gr> Cc: arch@FreeBSD.org, re@FreeBSD.org Subject: Re: Accounting changes Message-ID: <20070419113528.X2913@fledge.watson.org> In-Reply-To: <20070419101815.Y2913@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070419113528.X2913>