Re: Accounting changes

Robert Watson wrote:
What do you think of the idea of changing the file format a little to include a short file header at the front, and that the first field of that head is zero-filled u_int32_t, and the second a version number? Right now, the first field of the acct structure is the name of the command, which will always be a non-nul string, so always have a first character non-nul. If we see non-nul data in the file header's first field, we use the old structure layout, and otherwise we check the version number and use the new layout? This would provide backwards compatibility for reading old accounting data, which I would think would generally be desirable, and allow us to explicitly version the file in the future.


The sites I know of that use accounting don't care about CPU use in the sa(8) sense at all. They care about tracking commands run. While acct(5) doesn't do this extraordinarily well, it does it well enough to allow basic command execution logging and analysis. Hence the desire to be able to continue readding preserved acct(5) data files in the future.

I see three options for satisfying this requirement.

One is to move the existing acct.h into usr.bin/lastcomm, and add to lastcomm(1) and option to read legacy files. I don't like this approach, because it doesn't include sa(8) in the picture, and, more importantly, it doesn't scale well for future changes. Every time we change the type of a field of acct.h (for example widening ac_gid) we will have to add architecture-specific code in the legacy file reading module.

A variation of the above approach would be to create a library for reading legacy accounting data formats. I think this is an overkill, given that the two users are sa(8) and lastcomm(1), and of the two lastcomm appears to be really needed.

The approach I favor is to add to lastcomm an option to dump an accounting file in text format, and a second option to read text accounting data from stdin and write it out in the current accounting file format. Users can then either store accounting data in (compressed) text files, or pipe them through a pipeline that will transform the legacy format into the current one. (In the latter case they will need to keep through an upgrade a lastcomm(1) binary compiled to read the legacy format - I can provide the appropriate cvs incantation in UPDATING). This approach also simplifies the writing of test cases.


Diomidis - http://www.spinellis.gr
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Accounting changes
    ... Right now, the first field of the acct structure is the name of the command, which will always be a non-nul string, so always have a first character non-nul. ... This would provide backwards compatibility for reading old accounting data, which I would think would generally be desirable, and allow us to explicitly version the file in the future. ... Every time we change the type of a field of acct.h we will have to add architecture-specific code in the legacy file reading module. ... file in text format, and a second option to read text accounting data from stdin and write it out in the current accounting file format. ...
    (freebsd-arch)
  • date formats
    ... I am using Access 2003 to gather accounting data and create a table that is ... application requires the date format to be MM/DD/YYYY. ... and the Access Short Date Format use single digit month and days if month or ... together in a separate field, but I am checking to see if there is an easier ...
    (microsoft.public.access.queries)
  • Negative numeric data in parens in Excel but as minus in Access
    ... I am taking accounting data from Excel into Access to create reporting ... I want as the format in both. ... Prev by Date: ...
    (microsoft.public.access.externaldata)