lkml.org 
[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
    From
    Date
    > We might, however, put the magic into the implicit padding
    > of ac_flag (ugly, since this would require an arch dependant
    > definition of stuct acct), or put it into the uppermost
    > three bits of ac_flag itself

    First of all, none of this matters much if the format
    is given a sysctl. The old format is default for now,
    and the new one is default (only?) in a couple years.
    Sun appears to have done something like this.

    When fixing it, note that a 5-bit binary exponent
    with denormals would beat the current float format.

    Regarding the existing struct though...

    Let's take a close look at this. I think there are 2 bytes
    of padding on all Linux ports, and another 2 available
    on everything except maybe m68k and/or arm. (that is, ports
    that will put a u32 on any u16 boundry) Here is the current
    struct, compactly formatted with 64-bit blocking:

    struct linux_acct {
    char ac_flag; // Flags
    // 1 pad byte
    __u16 ac_uid; // Real User ID
    __u16 ac_gid; // Real Group ID
    __u16 ac_tty; // Control Terminal

    __u32 ac_btime; // Process Creation Time
    comp_t ac_utime; // User Time
    comp_t ac_stime; // System Time

    comp_t ac_etime; // Elapsed Time
    comp_t ac_mem; // Average Memory Usage
    comp_t ac_io; // Chars Transferred
    comp_t ac_rw; // Blocks Read or Written

    comp_t ac_minflt; // Minor Pagefaults
    comp_t ac_majflt; // Major Pagefaults
    comp_t ac_swaps; // Number of Swaps
    // 2 pad bytes (except m68k or arm maybe?)

    __u32 ac_exitcode; // Exitcode
    // hppa might pad this
    char ac_comm[17]; // Command Name
    // hppa might pad this
    char ac_pad[10]; // Padding Bytes
    // 1 pad byte (maybe 6 for hppa)
    };

    Just a sec... ARRRGH WHY DO PEOPLE LEAVE PADDING AND
    GENERALLY MIS-ALIGN THINGS ALL THE TIME??????

    So there you go. You have a pad byte after ac_flag
    at a known location, and a pad byte after ac_pad that
    might move a bit due to mis-alignments above it.


    -
    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    [W:3.040 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site