[lkml]   [2004]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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.

    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
    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:01    [W:0.020 / U:8.252 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site