Re: [PATCH] 2.6.x BSD Process Accounting w/High UID

[Arthur Corliss]

On Thu, 4 Mar 2004, Tim Schmielau wrote:

> In a first step, we could map all high uids onto one 'reserved' uid to
> avoid requiring new userspace tools.
> This is along the lines what I did when jiffies became 64 bits - just map
> larger times onto the maximum time representable with 32 bits.
>
> We didn't even exploit the fact that 34 bit times would be representable
> in the current format, because existing userspace tools would probably
> break then.
> At the time I did that change, it seemed to be common consensus that too
> few people cared about accurate BSD accounting to require new userspace
> tools.

First off:  there are no changes needed the current defacto accounting tools
on Linux (the GNU package).  As long as they can reference the correct size of
the struct (as defined in acct.h) they work just fine.  The GNU package
doesn't look like it's been updated since '98, and it works just fine with the
right header.  I mentioned that I did update glibc's sys/acct.h because it
uses that in preference over the kernel header.  Minor issue, but something
I'm looking at.

Second:  I don't want new userspace tools, either, but I do want the ones
I've got to work, which is what they don't do when it reports the lower bits
of the uid field on high uids.  In other words, the tools are *already*
broken.  I realise that I'm probably a corner case in that most admins will
never assign high uids, but that really doesn't make me feel better about
broken tools.  ;-)

> btw: if you actually push an incompatible change, could we do something
> about large times as well?

If the numbers we're logging are meaningless, then hell, yes, let's fix them
all!

	--Arthur Corliss
	  Bolverk's Lair -- http://arthur.corlissfamily.org/
	  Digital Mages -- http://www.digitalmages.com/
	  "Live Free or Die, the Only Way to Live" -- NH State Motto
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/