kobject_register() has the rude behavior that it will attempt to clean up
the kobject if kobject_add() fails. This replaces that with a WARN_ON() for
the return value, and leaves the cleanup to the caller.

This replaces the bus iterators bus_for_each_dev() and bus_for_each_drv().
Though no one in the kernel was using these, the MCA bus updates that are
about to appear depend on them.

They both now take a start pointer, which is the item to begin walking
the list from, if it is not NULL.

into osdl.org:/home/mochel/src/kernel/devel/linux-2.5-core

into osdl.org:/home/mochel/src/kernel/devel/linux-2.5-core

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."