During postprocessing, we get the information which modules we depend on 
(i.e. which modules export symbols we need to import) for free, so we
record it in .modinfo. This may allow us to remove the "depmod" program
at a later time, though for now it remains working as usual.

Doing the module post processing using some scripting with sed/grep etc
was doable, but performance is of course much better when we do it in C
instead, and it also allows for easier extensibility for additional
postprocessing for e.g. the MODULE_DEVICE_TABLE's.
  
Executing the new helper "modpost" will build the additional C code for all
modules at once, so we can just keep the hash table of exported symbols
in memory instead of rebuilding it for every module.

Since we rely on our list of all modules for building anyway, we
can as well use it to install the modules. So we don't need to
descend in that step anymore, speeding it up, though it's not
a particularly performance-critical area.

Since we'll have to always do module postprocessing shortly, we can as well
get rid of the special cased init/vermagic.o which needed to be compiled
before descending, and instead include the current version magic string
during post processing. For that purpose, the generation of the string is
moved from init/vermagic.c to include/linux/vermagic.h.

People who externally maintain modules will also be happy about that.

Currently, we are doing the final module link (.ko) at different places
(Makefile.build vs Makefile.modver) depending on CONFIG_MODVERSIONS.
Apart from being confusing, that also means we have this code path
duplicated, and the modversions path most likely gets little testing.
    
It's actually cleaner to just do the final link from Makefile.modver always,
performance-wise it's not a noticable difference, since we don't descend
in that step, but just use the list of modules generated during the build.
    
This step is also preliminary for doing additional postprocessing, e.g.
generating module alias information from PCI / USB device tables.

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

into redhat.com:/garz/repo/net-drivers-2.5

Just approving this as maintainer of i2o_scsi

This lets me put mca-legacy into drivers to fix them for now without
worrying about losing the fact they want more attention

There are no known cards outside of labs that used i2o_lan. The only
exception is the Redcreek VPN, which has its own driver anyway. Note
i2o_lan.h is left as i2o_config can still understand i2o_lan devices
such as the RedCreek.

The following patches should fix those last two issues - compiling boot.c
for UP and compiling proc.c by default.

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

  This is needed because mark_buffer_dirty is now checking if buffer is up to date.
  Noticed by Alex Tomas <bzzz@tmi.comex.ru>

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

into tetrachloride.(none):/mnt/stuff/kernel/2.5/cpufreq

into tetrachloride.(none):/mnt/stuff/kernel/2.5/agpgart

into tetrachloride.(none):/mnt/stuff/kernel/2.5/agpgart

into tetrachloride.(none):/mnt/stuff/kernel/2.5/cpufreq

New low level tms380 driver for Proteon 1392 / 1392+ cards
(port from existing 2.2 kernel code)

Add spinlock to fix race condition in tms380tr.

Fix startup of tmsisa to not register and unregister devices multiple
times, so hotplug doesn't run wild.

Add support for statically compiling tmsisa into kernel.

Remove unnecessary console SPAM during boot.

Fixed probing of ISA devices in tmsisa.

Fixed unsafe reference counting.

Fixed __init function causing Oops with new module system.

Rename tmsisa to skisa.

into redhat.com:/garz/repo/net-drivers-2.5

this trivial patch adds EEPRO100_PIO config option, which forces eepro100.c
driver to use pio instead of mmio. This option is necessary to support
onboard i82557 on sgi visual workstation.