and preparation for truly modular low level drivers.

before applying patches, for clarity and for keeping bk revision
history.

drivers/cdrom/cdrom.c is the only file (apart from include/linux/fcntl.h)
that includes asm/fcntl.h.  This changes that and should have no affect.

I need to do this before I consolidate the asm/fcntl.h files into
linux/fcntl.h (coming next - again).

This is needed since 2.5.32 to successfully mount a UFS partition.

I've been playing with different HZ values in the 2.4 kernel for a while
now, and apparantly Linus also has decided to introduce a USER_HZ
constant (I used CLOCKS_PER_SEC) while raising the HZ value on x86 to
1000.

On x86 timekeeping has shown to be relative fragile when raising HZ (OK,
I tried HZ=2048 which is quite high) because of the way the interrupt
timer is configured to fire HZ times each second.  This is done by
configuring a divisor in the timer chip (LATCH) which divides a certain
clock (1193180) and makes the chip fire interrupts at the resulting
frequency.

Now comes the catch: NTP requires a clock accuracy of 500 ppm.  For some
HZ values the clock is not accurate enough to meet this requirement,
hence NTP won't work well.

An example HZ value is 1020 which exceeds the 500 ppm requirement.  In
this case the best approximation is 1019.8 Hz.  the xtime.tv_usec value
is raised with a value of 980 each tick which means that after one
second the tv_usec value has increased with 999404 (should be 1000000)
which is an accuracy of 596 ppm.

Some more examples:
	  HZ Accuracy (ppm)
	---- --------------
	 100             17
	1000            151
	1024            632
	2000            687
	2008            343
	2011             18
	2048           1249

What I've been doing is replace tv_usec by tv_nsec, meaning xtime is now
a timespec instead of a timeval.  This allows the accuracy to be
improved by a factor of 1000 for any (well ...  any?) HZ value. 

Of course all kinds of calculations had te be improved as well.  The
ACTHZ constantant is introduced to approximate the actual HZ value, it's
used to do some approximations of other related values. 

Cset exclude: greg@kroah.com|ChangeSet|20020905153320|19047

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

into groveronline.com:/root/bk/linux-acpi

during the initcall sequence, after all CPUs have been brought up. 
mtrr_init() calls a static init_other_cpus(), which fires off a function 
on all other cpus to replicate the state across all of them. 

arch/i386/kernel/smpboot.c::smp_callin() had the following: 

#ifdef CONFIG_MTRR
       /*
        * Must be done before calibration delay is computed
        */
       mtrr_init_secondary_cpu ();
#endif


I couldn't figure this one out. The P4 manual says nothing about this, nor
find any other documentation about it. The P4 manual says only that state
must be synchronized across all CPUs, which it is. And, it happens before
anything else is executed on the other CPUs, and before any devices or
drivers have been brought up.

The cyrix mtrr code was also updated to handle this style of SMP initialization.

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux