parisc builds parisc / parisc64 from arch/parisc, but wants different
strings for uname -m, which it can now provide by overwriting
UTS_MACHINE in arch/parisc/Makefile.

(Matthew Wilcox)

It is used by arch specific Makefiles

Replaced by the more readable $(Q)$(MAKE) construct

Most definitions required were present in Makefile.lib, so delete the
definitions and include Makefile.lib.

Moved generic definitions to Makefile.lib,
This allows us to share all generic definitions between the different Makefiles.
Performance impact has been measured to less than 1%

gentbl is a program that generates some header files. The recent kbuild
changes have the "interesting" effect that this now outputs the header
files to the root directory of the kernel tree instead of
drivers/net/hamradio/soundmodem ...

The following patch fixes this breakage:

o Deleted subdir-n and subdir- handling in Makefile.build
o Deleted all host-progs related stuff in Makfile.modver
o In Makefile.modver also deleted everything related to composite objects
o Fixed an error when deleting a .ver file + .hdepend and then do make
  - filter-out in Makefile.modver was faulty

Traditionally, the individual components of a multipart module are
listed in <mod>-objs. Allow for using <mod>-y as well, as that turns
out to simplify declaring optional parts of multi-part modules, see
the converted examples in net/*/Makefile.

This change is backwards-compatible, i.e. not converted Makefiles
still work just fine.

Alright, so now actually all four phases are converted to new-style,
i.e. we call make -f scripts/Makefile.<phase> which includes the
actual subdir Makefile.

The obvious drawback is some code duplication between the four
scripts/Makefile.<phase>, which could easily be overcome including
shared parts, but since I'm going for maximum performance, I did not
for now.

Rules.make is empty now ;) (Well, not quite, since if it was 0 bytes,
make mrproper would remove it...)

Use the same way we came up with for "make clean" for
"make modules_install", gaining a nice speed-up.

Also, some cosmetics for scripts/Makefile.clean

$(call ...) has a measurable performance impact, so use the new
variable $(Q), which evaluates to @ when quiet to supress
the echoing of commands if not wanted.

IIRC, Keith Owens' kbuild-2.5 came up with that idea, so credit goes
there.

Including Rules.make after make -C stopped working with the
fixdep changes, so the other code trying to salvage backward
compatibility should go as well.

Rules.make is used in 4 phases, 
o generate modversions
o build
o install modules
o clean

split out the code specific to the phase and move it into 
scripts/Makefile.<phase>

The problem was that when the refcount hit 0, it was unconditionally
assuming that it had been added, which is wrong.  The patch below
corrects that, and fixes the Oops when loading the floppy driver.

into home.transmeta.com:/home/torvalds/v2.5/linux

into home.transmeta.com:/home/torvalds/v2.5/linux

Several ports (x86-64,ppc64,sparc64) which do 32bit ioctl emulation
have functions for drivers to let them define their own translation
handlers. So far it was a bit complicated to use because there
was no standard include file that declares the prototypes for this
stuff. Then drivers and other subsystems can start to declare their own
ioctl translation handlers.

This patch add include/linux/ioctl32.h to fix this.

The actual implementation is in arch specific code. It has been coordinated
with DaveM and Anton.

This patch is needed for the x86-64 merge I sent in separate mail.

There is currently no preprocessor symbol that the drivers can test
to see if they should use this. So far they have to check arch symbols.
This will be fixed later when all 64bit ports that need it add the dynamic
ioctl registration API too (that's ia64,s390x,mips64)

This fixes a few files that got lost with the last merge and merges
with 2.5.43/i386.  Only changes architecture specific files.

It depends on one other patch (for linux/ioctl32.h) which I'm sending
separately.

Changes:
- Include missing files (pageattr.c) and Makefile changes
- Update IA32 subsystem. Various small fixes and a big merge
  with sparc64.
- Change HZ to 1000
- Merge some of the 2.5.43/i386 profiling changes. No full oprofile yet.
- Fix many warnings
- Update defconfig
- Various other smaller cleanups and bugfixes.

        * switched to private queues
        * set ->queue

into home.transmeta.com:/home/torvalds/v2.5/linux

        * switched to private queues
        * set ->queue and ->private_data
        * switched to use of ->bd_disk/->rq_disk
        * merged private blocksize, etc. arrays into nbd_dev[]
        * cleaned up

        * switched to private queues
        * set ->queue and ->private_data
	* switched to use of ->rq_disk

	sbpcd.c: removes bogus duplicate definition of sbpcd_lock, use of
CURRENT (we are using private queue) and call of invalidate_buffers() in
->media_changed() (caller does it itself).  That went in a changeset from
davej - looks like a merge problem...
	sr.c: braino in ifdefed printk - s/disk/cd->disk/.  Thanks to jejb
for spotting that one...

into home.transmeta.com:/home/torvalds/v2.5/linux

into home.transmeta.com:/home/torvalds/v2.5/linux

into nuts.ninka.net:/home/davem/src/BK/sparc-2.5

This adds a set of list macros that make handling of list protected
by RCU simpler. The interfaces added are -

list_add_rcu
list_add_tail_rcu
	- Adds an element by taking care of memory barrier (wmb()).

list_del_rcu
	- Deletes an element but doesn't re-initialize the pointers in
	  the element for supporting RCU based traversal.

list_for_each_rcu
__list_for_each_rcu
	- Traversal of RCU protected list - takes care of memory barriers
	  transparently.

This first RCU helper patch adds a read_barrier_depends() primitive
to all archs which is NOP for archs that doesn't require an rmb()
for data dependent reads when writes are ordered using a wmb().
In reality, only alpha requires an rmb(), the rest are NOPs.
It is likely to be necessary in most situations that would use RCU.
Please apply.

 Description :

Sometime ago, during a discussion on lock-free lookups, it was
agreed that an additional memory barrier interface,
read_barrier_depends() that is lighter than an rmb(),
is necessary to make sure that data-dependent reads are not
re-ordered over this barrier. For many processors, data-dependency
enforces order, so this interface is a NOP, but for those that don't
(like alpha), it can be a rmb().

For example, the following code would force ordering (the initial
value of "a" is zero, "b" is one, and "p" is "&a"):

    CPU 0                           CPU 1

    b = 2;
    memory_barrier();
    p = &b;                         q = p;
                                    read_barrier_depends();
                                    d = *q;

because the read of "*q" depends on the read of "p" and these
two reads should be separated by a read_barrier_depends().  However,
the following code, with the same initial values for "a" and "b":

    CPU 0                           CPU 1

    a = 2;
    memory_barrier();
    b = 3;                          y = b;
                                    read_barrier_depends();
                                    x = a;

does not enforce ordering, since there is no data dependency between
the read of "a" and the read of "b".  Therefore, on some CPUs, such
as Alpha, "y" could be set to 3 and "x" to 0.  rmb()
needs to be used here, not read_barrier_depends().

The original discussion can be found at -
http://marc.theaimsgroup.com/?t=100259422200002&r=1&w=2

Explanation of the need for read_barrier_depends()
can be found at http://lse.sf.net/locking/wmbdd.html

This fixes a 'used but not declared' compile error

It ends up trying to list_del() from an uninitialized
list_head.