This is so other entities in the kernel can inform the bus about devices
that it either doesn't know about yet (like when using the firmware to 
enumerate the system) or that it wouldn't otherwise find (for the same 
reason, or because they're weird legacy devices that won't be probed for).

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

Talking to Vojtech about nicer config interfaces

highmem enabled, but not otherwise, and was always required).

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

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

   (Noticed by DaveM)

into mandrakesoft.com:/home/jgarzik/repo/net-drivers-2.5

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

For some reason, quota.h was derrived from BSD 4 clause code.  Thankfully,
UCB gave permission to remove the advert clause a couple of years ago, so
it's now okay for us to actually distribute this code.  The following patch
updates the header in quota.h.

this eliminates an infinite loop in rpciod if an RPC client's reference
counter accidentally goes negative.  i've been running this under load
since 2.5.30 with no ill effects.

This adds direct write and read from/to the user space to/from the SCSI
adapter.  If something (e.g., too high address) prevents direct
transfer, the existing driver buffer code is used.  The patch contains
functions to map and pin the user buffer pages so that this patch is not
dependent on kiobufs.  Similar functions are already used in sg.c.

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

Please import this patch. It updates the Config.help entry (which some
people requested) and cleans up coding a bit. No functional changes.

GCC can only inline functions when the function definition comes before
its use.

Recompute keybit when keycode table changes.
Stricter checks on input keycode/scancode values.

Device interfaces are the logical interfaces of device classes that correlate
directly to userspace interfaces, like device nodes. 

Device interfaces are registered with the class they belong to. As devices
are added to the class, they are added to each interface registered with
the class. The interface is responsible for determining whether the device
supports the interface or not. 

The interface is responsible for allocating and initializing a struct 
intf_data and calling interface_add_data() to add it to the device's list
of interfaces it belongs to. This list will be iterated over when the device
is removed from the class (instead of all possible interfaces for a class).
This structure should probably be embedded in whatever per-device data 
structure the interface is allocating anyway.

Devices are enumerated within the interface. This happens in interface_add_data()
and the enumerated value is stored in the struct intf_data for that device. 

Interfaces get a directory in driverfs under their class's directory. Each
time a device is added to the interface, a symlink is created in that 
directory that points to the device's directory in the physical hierarchy.
The name of this symlink is the interface-enumerated value of the device.

Device classes describe a type (or class) of device, like an input device
or network device, etc. This changeset defines a struct device_class that 
each subsystem is expected to implement and register with the core.

struct device_driver gains a devclass pointer which points to the class it
belongs to. When the driver is registered, it is added to the class's list
of drivers. Whenever a device is bound to that driver, it is added to the
class by calling the class's add_device callback. 

struct device gains a class_num field which is the per-class enumerated value
of the device. It is incremented each time a device is registered with the
class.

Each device class gets a driverfs directory in class/<class name> and two
subdirectories: 'devices' and 'drivers'. For each device added to the class,
a symlink is created in the devices/ directory that points to the device's
directory in the physical hierarchy. The name of the symlink is the enumerated
number the device got when it was registered with the class.

For each driver that's added to the class, a symlink is created in the class's
drivers/ directory that points to the driver's directory. The name of this 
symlink is a concatenation of <bus name>:<driver name> (to prevent namespace
conflicts of drivers with the same name on different buses).
 

as functions interfacing to the input core. PC-Speaker handling is
moved to a separate file. Uinput is moved to a input/misc directory.

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

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

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

into zephyr.physics.uiowa.edu:/home/kai/src/kernel/v2.5/linux-2.5.make

Greg Banks:

A very significant space is missing from an "if" expression
in drivers/video/Config.in.

Greg Banks:

Symbols CONFIG_BLK_DEV_NS87415, CONFIG_BLK_DEV_TRM290, CONFIG_DSCC4, and
CONFIG_USB_SERIAL_SAFE_PADDED had spurious (EXPERIMENTAL) tags in their
banners.
Symbol CONFIG_INPUT_UINPUT was missing an (EXPERIMENTAL) tag in it banner.

The mips and parisc ports both defined 'Loadable module support' menus,
despite including an identical menu from init/Config.in.

Greg Banks:

The symbol CONFIG_SOUND_CMPCI_FMIO is declared with a "hex" statement,
immediately preceded by a "define_hex" with the same value as the
default value from the "hex".  In config and xconfig, this has no effect;
in menuconfig it prevents the user selecting any value other than the
default.