into hera.kernel.org:/home/hch/BK/xfs/linux-2.5

From Pengcheng Zou <pczou@redflag-linux.com>:
>
> Orignally DN_MODIFY is issued on readv while DN_ACCESS is issued on writev,
> which is obviously wrong. This patch fixes such problem.

This is the equivalent patch for 2.5.50+.

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

This fixes the umask/fmask/dmask confusion in vfat.

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

into redhat.com:/home/jgarzik/repo/misc-2.5

Badness results.

to declare things on your own!

This implements the mmu stuff for the mmuless cpus - a lot of it stubs
to avoid ifdefs in core code

Basically a nop for MMU based systems

Primarily adds Nvidia + some i845G

Add Zwane
Remove soundmodem stuff
Update snapgear

By Kai Germaschewski:

 "Well, I have another solution, which doesn't need additional Makefile
  magic or anything.

  I just put the module name into each .o file where <linux/module.h> is
  included. Putting it into the section .gnu.linkonce.modname has the effect
  that even for multi-part modules, we only end up with one copy of the
  name.

  Caveat: I'm using the preprocessor macro KBUILD_MODNAME to know what to
  put into .gnu.linkonce.modname. The following used to happen:

  (drivers/isdn/eicon/Makefile)

  divas-objs := common.o Divas_mod.o ...
  eicon-objs := common.o eicon_mod.o ...

  Divas_mod.o is compiled with -DKBUILD_MODNAME=divas
  eicon_mod.o is compiled with -DKBUILD_MODNAME=eicon
  common.o is compiled with -DKBUILD_MODNAME=divas_eicon

  So in the case above, both divas.o and eicon.o would end up with
  a .gnu.linkonce.modname section containing "divas_eicon"

  My fix to this is to not define KBUILD_MODNAME when compiling an object
  whilch will be linked into more than one module - so common.o gets no
  .gnu.linkonce.modname section at all. Works fine here.

  Now, doing this I remove one of the reasons why we would need modules
  linked as '.ko' ;), but it seems much cleaner than generating a temporary
  file, using objcopy etc."

On the v850, the elf toolchain uses a `_' prefix for all user symbols
(I'm not sure why, since most toolchains seem to have dropped this sort
of thing).

The attached patch adds the ability to deal with this, if the macro
MODULE_SYMBOL_PREFIX is defined by <asm/module.h>.  This only affects
places where symbol names come from the user, e.g., EXPORT_SYMBOL, or
the explicit symbol-names used in kernel/module.c itself.

[Tweaked a little by Rusty, original by Miles Bader]