From owner-freebsd-arch@FreeBSD.ORG Thu Apr 19 20:25:10 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 376C816A401; Thu, 19 Apr 2007 20:25:10 +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 0AAF413C46A; Thu, 19 Apr 2007 20:25:09 +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 47B0546D68; Thu, 19 Apr 2007 16:25:09 -0400 (EDT) Date: Thu, 19 Apr 2007 21:25:09 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Diomidis Spinellis In-Reply-To: <4627A6C3.2070409@aueb.gr> Message-ID: <20070419212253.L2913@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> <4627A6C3.2070409@aueb.gr> 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 20:25:10 -0000 On Thu, 19 Apr 2007, Diomidis Spinellis wrote: > 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: Are there any alignment/padding considerations we should be taking into account with the last two fields to make sure they are consistently aligned with respect to the end of the record as new fields are added to the middle? Robert N M Watson Computer Laboratory University of Cambridge > > #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 >