32-bit process accounting

	Hi,

	According to Andrew's must-fix list:

"32bit uid support is *still* broken for process accounting."

Ok, so I went and tried to see why we can't just use uid_t/gid_t for
the uid, gid fields on struct acct.

I saw the GNU acct source, and it uses unsigned int fields on the hash
tabels and doesn't assume any 16-bit only fields on the acct structure.

So, it seems to me that the only reason we still have broken 32-bit
process accounting is so that old tools can behave nicely. Please tell me other reasons as I couldn't find them.

There are 2 patches attached.

The first, does the obvious uid_t/gid_t replacement..since it defines
16/32-bits for UIDs on a per-architecture basis.

The second, uses CONFIG_UID16 as a basis for forcing 16-bit UIDs.

I'd like to request review of these patches and pointers on what I'm
missing to get this problem fixed.

Thanks,

Felipe

@@ -41,8 +41,13 @@
  *	No binary format break with 2.0 - but when we hit 32bit uid we'll
  *	have to bite one
  */
+#ifdef CONFIG_UID16
 	__u16		ac_uid;			/* Accounting Real User ID */
 	__u16		ac_gid;			/* Accounting Real Group ID */
+#else
+	uid_t		ac_uid;			/* Accounting Real User ID */
+	gid_t		ac_gid;			/* Accounting Real Group ID */
+#endif
 	__u16		ac_tty;			/* Accounting Control Terminal */
 	__u32		ac_btime;		/* Accounting Process Creation Time */
 	comp_t		ac_utime;		/* Accounting User Time */

@@ -41,8 +41,8 @@
  *	No binary format break with 2.0 - but when we hit 32bit uid we'll
  *	have to bite one
  */
-	__u16		ac_uid;			/* Accounting Real User ID */
-	__u16		ac_gid;			/* Accounting Real Group ID */
+	uid_t		ac_uid;			/* Accounting Real User ID */
+	gid_t		ac_gid;			/* Accounting Real Group ID */
 	__u16		ac_tty;			/* Accounting Control Terminal */
 	__u32		ac_btime;		/* Accounting Process Creation Time */
 	comp_t		ac_utime;		/* Accounting User Time */

On Fri, 23 Apr 2004, Felipe W Damasio wrote:

@@ -41,8 +41,8 @@

This breaks binary compatibility, so you should change the comment as well.

Seriously, it's of course better not to break binary compatibility, as in this patch
http://www.lib.uaa.alaska.edu/linux-kernel/archive/2004-Week-11/1337.html

I have to admit that things are moving a bit slow as I had no spare time to push this patch. Will try to do that in the next week.

Tim