[parisc-linux] time_t, size_t, off_t, ...

[Paul Bame]

= time_t itself is normally a long because historically (pre ANSI/POSIX) back
= when men where men and adb was the coolest debugger on the planet it was
= the case that time() foo was a function using longs
= 
= [Random historical aside - very early C didnt support passing long as an 
= argument hence time(&foo) not foo=time()]

I cut my Unix teeth on pdp11/v6-7 -- counts as very early I think :-)

= I know of no kernel reason. If you are using a 1KHz system clock then it
= may be handy to up the loop time for the counter to above 50 days by using
= long.

I'm setting clock_t to 64 bits on wide kernel FYI, but will keep time_t
and suseconds_t at 32 bits until there's a problem.  Won't effect
32-bit userspace if it has to change.

= > (4)	I thought I could get away with making sigset_t.sig int[] therefore
= > 	32 bits everywhere.  It would save several 32/64 syscall
= > 	wrappers (and increase speed).  However this little piece
= > 	in kernel/signal.c is a hard-coded assumption that .sig[] is
= > 	an array of long, and was a bitch to find:
= > 
= > 		unsigned long i, *s, *m, x;
= > 		s = tsk->pending.signal.sig;
= 
= Eep. Its not unreasonable to suggest to Linus that gets fixed 8)

Yeah, too bad I'm too much of a wimp to sign up for l-k -- already get
more e-mail than I read :-(  

= On the 64bit port _please_ use a 64bit ino_t. It'll possibly tickle the odd
= other problem but post 2.4 the main kernel has to move to 64bit ino_t to make
= NFSv3 and XFS sanely work. That may well let you relax and look smug as the
= rest of the world suffers 8)

Ok, I'll use 64-bit ino_t on parisc64.

	-P