Re: [PATCH] 2.6.x BSD Process Accounting w/High UID

From: Jeremy Jackson
Date: Tue Mar 09 2004 - 11:19:15 EST

Arthur Corliss wrote:

If the numbers we're logging are meaningless, then hell, yes, let's fix them

I believe the answer (to seamless backwards compatibility) lies in struct acct's ac_pad[10] member.

3 options exist that I can see:

1) put the high 16 bits in there, with a magic # (at then end of?) ac_pad. THe old tools will be none the wiser, the new tools will autodetect which format the acct file is in. Ugly but easy.

2) just make the uid/gid 32bits, and put a magic# (at the end of?) ac_pad. The old tools will choke, but the new tools will autodetect. If you push the new tools out a couple of years ahead, then merge the fix, acceptance will be fairly smooth. Clean but painful.

3) make the split of 16 bits interim with one magic#, make the tools detect 3 formats, and in a few years, switch from the bastard 32bit to the clean one (different magic #). This will give tools time to become standard.
Combines best of both of the above.

You can do the above with the time stuff too, but 10 bytes spare might constrain things a bit. Heck, make the struct bigger, as long as there is a magic #, userspace should be ok. Right now, "file" command can't tell what the heck the file is. Bit wasteful to put magic in every record though.

While you're at it, make a switch for a tool that prints out ac_exitcode, without reading the binary acct file (or it's dump).

Jeremy Jackson
Coplanar Networks

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at