line.h.

arch/um/kernel/tt.

the 2.4 pool.
Also merged some other cleanups.

to arch/um/kernel/tt/ptproxy works.

arch/um/kernel/tt/ptproxy.

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

Also there is one sound header that was modified in the same way.

Also convert cmipci to C99 designated initializers style

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

Check for ->bd_invalidate moved from rescan_partitions() to the only caller
that
	a) needs that check and
	b) doesn't do it already.

Fixes the problem with BLKRRPART which doesn't want that check at all...

 - example in Documentation/DocBook/procfs_example.c uses
   MOD_..._USE_COUNT for no reason.

 - alpha/kernel/srm_env.c uses MOD_...USE_COUNT for no reason _and_ does
   lovely stuff like strlen() on user-supplied pointers,
   copy_from_user() with unverified size, half-kilobyte on-stack arrays,
   etc.  Fixed.

 - s390{,x}/kernel/debug.c: set ->owner instead of playing with
   MOD_..._USE_COUNT in ->open()/->release()

 - mwavedd.c: gratitious use of MOD_..._USE_COUNT

 - uinput.c: ditto

 - radio/miropcm20-rds.c: set ->owner, remove MOD_..._USE_COUNT from
   ->open()/->release(), fixed an obvious race in the former (it checked
   that nobody else had device opened, then did kmalloc() with
   GFP_KERNEL, then marked device as opened).

All callers of devfs_find_and_unregister() pass 0 in 6th argument.  All
uses of that function either pass 0 in 3rd and 4th argument (in which
case the 5th is ignored) or pass the existing pathname in the 2nd (in
which case 3rd, 4th and 5th are ignored).  In all cases the first
argument can be trivially made NULL.

devfs_find_and_unregister() is left as-is.  All existing callers
converted to new helper - devfs_remove(pathname).  Said beast does
equivalent of devfs_find_and_unregister(NULL, pathname, 0, 0, 0, 0);

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

into mulgrave.(none):/home/jejb/BK/scsi-for-linus-2.5

into mulgrave.(none):/home/jejb/BK/scsi-for-linus-2.5

Here is another version of the scsi_mid_low_api.txt
document. It adds descriptions of functions supplied
by the mid level for a LLD (lower level driver) to call.
It is also tries to describe the two, alternate
registration scenarios. How do the terms:
"hotplug initialization model" and "passive
initialization model" sound?