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

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.

Greg Banks:

The symbol CONFIG_DEBUG_SPINLOCK was defined twice identically
in the same file...three lines apart.

Greg Banks:

A number of dep_bools and dep_tristates have architecture constants
(e.g. CONFIG_X86) as dependencies.  Such symbols have the property
that their value is constant for any particular arch tree, and is
either "y" or "", neither of which have any effect as dependencies,
so the dependencies have no effect.  This patch removes some of them.

Greg Banks:

The menu 'AX.25 network device drivers' contained as its first
item a comment with identical banner.  This is pointless duplication,
but more to the point it confused gcml2 unnecessarily.

Cset exclude: torvalds@home.transmeta.com|ChangeSet|20020821235957|57282

This patch simply ensures that 'setting the MTRR' is atomic.  This is
important since HT CPU's may share some MTRR state.

- Do not use PC-relative branch/call in Ultra-III+ parity error
trap vectors, we patch this into the trap table and then the PC-relative
values are wrong.
- When we take an irrecoverable trap at tl > 0, save away the full
trap stack to the kernel stack, then log it from the C code handler.

- Some places need to include sched.h because the already include ptrace.h
- CLONE_{SET,CLEAR}TID support
- Clear PT_DTRACE when execve succeeds.
- Add security bits to ptrace
- Add sys_security to syscall tables.

- Some places need to include sched.h because the already include ptrace.h
- CLONE_{SET,CLEAR}TID support
- Clear PT_DTRACE when execve succeeds.
- Add security bits to ptrace and sys32_execve
- Add sys_security to syscall tables.

- futex uses int as its atomic word type, we pass in user_tid
to the futex routines, so the types must match

- flush_dcpage_cheetah sized wrongly, it is 11 not 9 insns now
- xcall_report_regs and xcall_promstop should use etrap_irq not etrap

into nuts.ninka.net:/home/davem/src/BK/net-2.5

into nuts.ninka.net:/home/davem/src/BK/sparc-2.5

into tp1.ruhr-uni-bochum.de:/home/kai/linux-2.5.make

This patch makes three small changes to nfsd_readdir().

First, the 'filldir' routine for NFSv4 may return an arbitrary error,
which should become the return value for nfsd_readdir().  I implemented
this by adding an 'nfserr' field to the 'struct readdir_cd'.

Second, in NFSv4 the caller of nfsd_readdir() will specify an attribute
bitmap, which must be communicated to the 'filldir' routine.  I implemented
this by adding a @bitmap parameter to nfsd_readdir() and a corresponding
field in the 'struct readdir_cd'.  (The bitmap is not interpreted in any
way by nfsd_readdir().)

Finally, NFSv4 defines a new error nfserr_readdir_nospc, which indicates
that there was not enough buffer space to encode a single entry.

NFSv4 defines a new field in the ACCESS response: a bitmap to indicate
which access bits requested by the client are "supported", i.e. meaningful
for the object in question.

This patch adds a new parameter @supported to nfsd_access(), so that
nfsd_access() can set the value of this bitmap.

File creation in NFSv4 is almost the same as in NFSv3, with one minor
difference.  If an UNCHECKED create is done, and the file exists, we
don't set any attributes.  Exception: If size==0 is specified as part
of the attributes, then we do truncate the file, but only after processing
the rest of the OPEN.  (File creation is always part of an OPEN request.)

This patch defines a new argument *truncp to nfsd_create_v3(), which
will be NULL for v3 requests.  For v4 requests, it will point to a
variable which should be set to 1 if file truncation is still needed.

The logic in nfsd_create_v3() is changed as follows: If
  - *truncp is not NULL
  - the create is UNCHECKED
  - the file exists
then nfsd_create_v3() returns immediately.  If size==0 is specified,
then *truncp is set to 1.

This is kind of a hack, but the only alternative I could see was creating
a new routine nfsd_create_v4(), which would be identical to nfsd_create_v3()
except for this point.

If nfsd_unlink() is called with @type equal to 0, then let it do the
right thing regardless of the type of the file being unlinked.  This
is needed for the NFSv4 REMOVE operation, which works for any type of
file, even directories.

Sanity check COMMIT arguments by ensuring that (start)+(length) < 2^64.
The check is done in a way which is free of signedness pathologies in
all cases.

This change was inspired by pynfs, Peter Astrand's regression testsuite
for NFSv4 servers.  The change is necessary for all of the COMMIT tests
to pass.  However, it's a little open to debate whether the change is
really needed.  I'm curious to hear the opinions of other developers.

Change fh_compose() so that it will do the right thing if fhp==res_fh.
(This is convenient in the NFSv4 LOOKUP operation, which _replaces_
CURRENT_FH with the filehandle obtained by lookup.)

This requires extracting the interesting parts of the reference
filehandle first, then calling fh_put if it is a re-use.