Messages in this thread | | | Subject | Re: [PATCH] 2.6.x BSD Process Accounting w/High UID | From | Albert Cahalan <> | Date | 09 Mar 2004 20:59:11 -0500 |
| |
> 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/
| |