Replace the numbers by symbolic constants - doesn't help yet, since
we just go 0 -> ST_0, 1 -> ST_1, ... - but that'll change ;)

Add a helper function to prepare for and start dialing, removing duplicated
code from isdn_tty.c/isdn_net.c.

Move some parts of the big switch statement in isdn_net.c into their own 
functions.

Instead of having a number of arrays containg various bits of per-slot
data, start aggregating this data in a struct, and then have one
instance of this struct per slot.

Remove some of the old functions which used to take (driver,channel)
pairs, as they are superseded by isdn_slot_* functions now.

It's role has been taken over by .isdn_slot

A small step in cleaning up isdn.o, fixing various bugs on the error paths.

Don't know when that broke, but somebody seems to be using "msg" in another
context - since we don't need the union to be named at all, it's easy to
fix.

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

using a system call from kernel space. 

This avoids one level of hidden code, and makes what happens
much more explicit (and speeds it up too, fwiw)

This "warning fix" bug report is actually an OOPS bugfix.

locks_unlock_delete is buggy in a couple of different ways (previously
reported by Brian Dixon). Rather than fix it, this patch simply deletes
it and uses the normal posix file locking mechanisms to remove all locks
in locks_remove_posix instead.

Make cpu_relax() on all architectures a gcc barrier to match x86.

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

o Corrected dependencies for parportbook
o Introduced do_cmd, thus adhering to KBUILD_VERBOSE and make -s

do_cmd is a nice shorthand when creating rules that in one line
shall adhere to KBUILD_VERBOSE and make -s.
So far the only user is (will be) the docbook makefile

file locking LSM update

An acct flag was added to do_munmap, true everywhere but in mremap's
move_vma: instead of updating the arch and driver sources, revert that
that change and temporarily mask VM_ACCOUNT around that one do_munmap.

Also, noticed that do_mremap fails needlessly if both shrinking _and_
moving a mapping: update old_len to pass vm area boundaries test.

If we support mmap MAP_NORESERVE, we should support it on shared
anonymous objects: too bad that needs a few changes.  do_mmap_pgoff pass
VM_ACCOUNT (or not) down to shmem_file_setup, flag stored into shmem
info, for use by shmem_delete_inode later.  Also removed a harmless but
pointless call to shmem_truncate.

Update Doc and remove FIXME comment from fork.c now accounting right.

do_mmap_pgoff's (file == NULL) check was incorrect: it caused shared
MAP_ANONYMOUS objects to be counted twice (again in shmem_file_setup),
and again on fork(); whereas the equivalent shared /dev/zero objects
were correctly counted.  Conversely, a private readonly file mapping
was (correctly) not counted, but still not counted when mprotected to
writable: mprotect_fixup had pointless "charged = 0" changes, now it
does vm_enough_memory checking when private is first made writable
(but later we may want to refine behaviour on a noreserve mapping).

Also changed correct (flags & MAP_SHARED) test in do_mmap_pgoff to
equivalent (vm_flags & VM_SHARED) test: because do_mmap_pgoff is
dealing with vm_flags rather than the input flags by that stage.

Remove vm_unacct_vma function: it's only used in one place,
which can do it better by using vm_unacct_memory directly.

do_mmap_pgoff clears MAP_NORESERVE from vm_flags when VM accounts
strictly: but it's not in vm_flags, it's in flags (and tested there).

There is no point in do_mremap clearing MAP_NORESERVE from its flags:
it has already validated that only the MREMAP_ flags can be set,
and it has no use for MAP_NORESERVE in the code that follows anyway.

shmem_notify_change and shmem_file_write be careful about overflowingly
large loff_t before shifting it into unsigned long for vm_enough_memory.
Rename SHMEM_MAX_BLOCKS to SHMEM_MAX_INDEX (to avoid confusion with
512-byte blocks), define SHMEM_MAX_BYTES from it.

But 2.5 vmtruncate lacked the s_maxbytes error handling which
shmem_notify_change now expects: bring it in from the -dj tree.
shmem_file_write error handling needs a closer look later on.

Repeated overnight kernel builds in tmpfs showed insane Committed_AS
by morning.  The main bug was that shmem_file_write was passing
(newsize-oldsize)>>PAGE_SHIFT to vm_enough_memory, but it has to be
((newsize>>PAGE_SHIFT)-(oldsize>>PAGE_SHIFT)) - imagine 1k writes.

But actually, if we're going to do strict accounting, then we should
round up to next page not down - use VM_ACCT macro throughout (needs
unusual mix of PAGE_CACHE_SIZE with PAGE_SHIFT); and must count one
page for a long symlink.

Currently there is no way to find out the effective object size of a slab
cache.  XFS has lots of IRIX-derived code that want to do zalloc() style
allocations on zones (which are implemented as slab caches in XFS/Linux)
and thus needs to know about it.  There are three ways do implement it:

a) implement kmem_cache_zalloc
b) make the xfs zone a struct of kmem_cache_t and a size variable
c) implement kmem_cache_size

The current XFS tree does a) but I absolutely don't like it as encourages
people to use kmem_cache_zalloc for new code instead of thinking about how
to utilize slab object reuse.  b) would be easy, but I guess kmem_cache_size
is usefull enough to get into the kernel.  Here's the patch:

actual implementation and avoid confusion.

I just duplicated the method used in drivers/net/tulip/de2104x.c

pointed out by Sam Ravnborg

into tp1.ruhr-uni-bochum.de:/home/kai/kernel/v2.5/linux-2.5.make-fix

into tp1.ruhr-uni-bochum.de:/home/kai/kernel/v2.5/linux-2.5.make-fix

This should do the trick.