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

[Jeremy Jackson]

Arthur Corliss wrote:

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

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.

or
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).

Cheers,
--
Jeremy Jackson
Coplanar Networks
http://www.coplanar.net

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/