Accounting changes
Diomidis Spinellis
dds at aueb.gr
Fri Apr 20 05:39:21 UTC 2007
Rick C. Petty wrote:
> On Fri, Apr 20, 2007 at 12:45:53AM +0300, Diomidis Spinellis wrote:
>> If we follow the route of allowing the records to be read from both
>> ends, we'll have to think of a construct that will portably maintain
>> ac_flags at the same offset from the end as in the old struct acct.
>> Proposals welcomed!
>
> How about rearranging the struct to have the fixed-sized fields first,
> followed by the variable-sized fields. In fact I thought that was the
> recommended practice..
The new structure has to provide backwards compatibility with the old
structure for a program reading a single record either from the
beginning of a file or from its end (backwards). This is why ac_flag
and ac_len2 (which is a copy of ac_len) have to be in the end.
A program reading backwards (e.g. lastcomm(1)) will first read ac_flag.
If ANVER is set, it will then read ac_len2, and then the rest of the
structure. It will the interpret the structure based on ac_version. If
ANVER is not set, the structure is in the old format and the program
will read the old struct acct.
A program reading forwards will first examine ac_zero. If it is zero it
will process the structure based on ac_len and ac_version. Otherwise
the structure is in the old format and the program will read the old
struct acct.
- dds
> i.e.:
>
>> struct nacct {
>> u_int8_t ac_zero; /* zero identifies new version */
>> u_int8_t ac_version; /* record version number */
>> u_int16_t ac_len; /* record length */
>>
>> char ac_comm[AC_COMM_LEN]; /* command name */
>> u_int16_t ac_len2; /* record length */
>> u_int8_t ac_flag; /* accounting flags */
>
>> float ac_utime; /* user time */
>> float ac_stime; /* system time */
>> float ac_etime; /* elapsed time */
>> time_t ac_btime; /* starting time */
>> uid_t ac_uid; /* user id */
>> gid_t ac_gid; /* group id */
>> float ac_mem; /* average memory usage */
>> float ac_io; /* count of IO blocks */
>> __dev_t ac_tty; /* controlling tty */
>
> -- Rick C. Petty
More information about the freebsd-arch
mailing list