lkml.org 
[lkml]   [2004]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] 2.6.x BSD Process Accounting w/High UID
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:01    [from the cache]
©2003-2011 Jasper Spaans