From owner-freebsd-arch@FreeBSD.ORG Thu Apr 19 17:29:17 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 C7DAA16A400; Thu, 19 Apr 2007 17:29:17 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from blue.servers.aueb.gr (blue.servers.aueb.gr [195.251.255.132]) by mx1.freebsd.org (Postfix) with ESMTP id 466B513C455; Thu, 19 Apr 2007 17:29:16 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from [195.251.249.152] ([::ffff:195.251.249.142]) by blue.servers.aueb.gr with esmtp; Thu, 19 Apr 2007 20:29:15 +0300 id 000D11F1.4627A6EB.0000054C Message-ID: <4627A6C3.2070409@aueb.gr> Date: Thu, 19 Apr 2007 20:28:35 +0300 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061211 SeaMonkey/1.0.7 MIME-Version: 1.0 To: Robert Watson 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> In-Reply-To: <20070419101815.Y2913@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 17:29:17 -0000 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. I will work on developing a mechanism for backwards compatibility. Adding a version and length field in each record as you now propose is I think the way to go. However, it is not trivial, because lastcomm(1) often reads the file backwards. One approach would be to add a flag in ac_flags indicating a new version, and second copy of the length field before ac_flags. Thus, the new structure would be something like: #define AC_COMM_LEN 16 struct acct { char ac_zero; /* zero identifies new version */ char ac_version; /* record version number */ u_int16_t ac_len; /* record length */ /* Business as usual: */ char ac_comm[AC_COMM_LEN]; /* command name */ comp_t ac_utime; /* user time */ comp_t ac_stime; /* system time */ comp_t ac_etime; /* elapsed time */ time_t ac_btime; /* starting time */ uid_t ac_uid; /* user id */ gid_t ac_gid; /* group id */ u_int16_t ac_mem; /* average memory usage */ comp_t ac_io; /* count of IO blocks */ __dev_t ac_tty; /* controlling tty */ /* Changes here: */ u_int16_t ac_len2; /* record length */ #define AFORK 0x01 /* forked but not exec'ed */ /* ASU is no longer supported */ #define ASU 0x02 /* used super-user permissions */ #define ACOMPAT 0x04 /* used compatibility mode */ #define ACORE 0x08 /* dumped core */ #define AXSIG 0x10 /* killed by a signal */ #define ANVER 0x20 /* new record version */ u_int8_t ac_flag; /* accounting flags */ }; This structure allows the file to be read in both directions, and also provides backwards compatibility. Diomidis