This was never used, and a bad idea to begin with. 

The kobject core no longer references a subsystem directly through a kobject,
instead using the kobject's dominant kset to reference the subsystem. The 
registrants of kobjects have been fixed up. 

To aid in this process, a few helpers were introdcuced: 

- kobj_set_kset_s(obj,subsys)
- kset_set_kset_s(obj,subsys)
- subsys_set_kset(obj,subsys)

that set the kset ptr of embedded kobjects for objects that have different
embedded types. See include/linux/kobject.h for more description and usage.


struct subsystem::kobj is also removed, relying solely on a subsystem's
embedded kset for hierarchy information.  Since this requires modification
of the subsystem declarations, a helper macro has been defined:

decl_subsys(name,type)

which initializes the name and ktype fields of the subsystem's embedded
kset. All the subsystem declarations have been fixed up.

struct kset is what struct subsystem should have originally been called. It
is a set of kobjects, and nothing more, with a much less confusing name than
'subsystem.'

struct kset contains an embedded kobject, making it possible to represent it
in the object hierarchy, and sysfs. This also provides a means for objects
to easily express a list of subordinate objects. 

struct subsystem still exists, and contains an rwsem, which its subordinate
ksets use to protect their lists. 

An arbitrary number of ksets may belong to a subsystem. A ksets specifies
the subsystem it belongs to via its ->subsys field. 

struct subsystem also contains a default kset, which may be used without
having to define a separate kset. 

The objects that defined subordinate subsystems (bus and class drivers) have
been converted to use subordinate ksets instead.


Note that the usage of ksets is flexible. 
- ksets may contain a list of objects of any type, not just kobjects.
- The objects registered with a kset do not have to be registered.
- ksets themselves do not have to be registered. One can be used by
  simply calling kset_init(). 
- ksets do not need a name if they are not registered. 
- Note however that locking must be done manually in these cases.

- Remove unused class_list.
- Use lists in subordinate subsystems for storing lists of devices and
  drivers.
- Rename 'drvsubsys' to 'drivers' and 'devsubsys' to 'devices', to be more
  meaningful.

- Remove devices list, in favor of using the list in the subordinate
  devices subsystem.
- Rename devsubsys to 'devices' and drvsubsys to 'drivers'.
- Use bus's rwsem when iterating over drivers, instead of the 
  subordinate driver subsystem's. (We use that one when adding the 
  driver, and binding it to devices).

This is the first step in morphing struct subsystem into something meaningful.

A subsystem is defined simply as a list of kobjects of a certain type, which
is far too generic. A subsystem should be representative of a large entity
of code (i.e. a subsystem of the kernel), not just a simple list. 

This changeset:

- Creates struct kobj_type, a descriptor of the type a kobject is embedded
  in.

- Extracts the fields that are specific to a particular object type from
  struct subsystem and puts them in struct kobj_type, which are
  - the object's release method.
  - the sysfs operations for the object type.
  - the default attributes of the object type.

- Adds ptr to struct kobject to point to its type descriptor. 

- Converts the existing subsystem definitions to define struct kobj_type. 


struct kobj_type's are not registered, as they do not have any explicit
representation in the object hierarchy, nor do they have any fields that
need runtime initialization. 

A kobject's ktype should be set when it is registered, like its subsystem.
Note this obviates the need for defining a struct subsystem when an object
type does not need to be kept in a global list. 

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

sh_link is a 32-bit field on 64 bit archs, so a bad choice to store
module section offsets, and also INIT_OFFSET_MASK is out of range.

So switch to using sh_entsize instead.

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

arch/alpha/kernel/ to the config options that need them.  Fix
a few build problems for XLT and RX164.

By a suggestion from David Mosberger: use this new version of
compat_jiffies_to_clock_t, which is more appropriate on 64-bit hosts
that don't have overflow issues.

It does better rounding and will not fail if COMPAT_USER_HZ > HZ.

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

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

(based upon 2.4 patch from Richard Baverstock <beaver@gto.net>)

Right now its the only VIA AGP 3.0 chipset. At some point in
time it may become via-agp3.c, but until then its cleaner to
seperate this from the VIA AGP 2.0 driver.

The 2.0 driver will still work on a KT400 with a 2.0 compliant graphic
card present. If the 2.0 driver finds the bridge in 3.0 mode, it aborts.
Likewise, the 3.0 driver will abort if the bridge is in 2.0 mode.

Confused yet?

Currently, only the K8 GART needs this, but this is cleaner than
exporting the agp_reserved_memory variable.

intel_agp_init() must not be declared static for explicit early
initialization to work (ie i810fb).