RFC: bus_type and device_class merge (or partial merge)

[Adam J. Richter]

	If there is a more specific mailing list than lkml for discussing
the generic driver model, please feel free to redirect me.

	I'm thinking about trying to embed struct device_class into
struct bus_type or perhaps just eliminate the separate struct
bus_type.  The two structures are almost identical, especially
considering that device_class.devnum appears not to be used by
anything.

struct bus_type {
	char			* name;

	struct subsystem	subsys;
	struct subsystem	drvsubsys;
	struct subsystem	devsubsys;
	struct list_head	devices;
	struct list_head	drivers;

	int		(*match)(struct device * dev, struct device_driver * drv);
	struct device * (*add)	(struct device * parent, char * bus_id);
	int		(*hotplug) (struct device *dev, char **envp, 
				    int num_envp, char *buffer, int buffer_size);
};

struct device_class {
	char			* name;
	u32			devnum;

	struct subsystem	subsys;
	struct subsystem	devsubsys;
	struct subsystem	drvsubsys;
	struct list_head	drivers;
	struct list_head	devices;

	int	(*add_device)(struct device *);
	void	(*remove_device)(struct device *);
	int	(*hotplug)(struct device *dev, char **envp, 
			   int num_envp, char *buffer, int buffer_size);
};

	At first appearance, a bus_type (PCI, USB, etc.) and a
device_class (network devices, input, block devices), may seem like
opposite ends of the device driver abstraction, but really I think
these are basically the same, and, more importantly, there can be many
layers of these interfaces, and the decision about which are bus_types
and which are device_classes is causing unnecessary coplexity.  For
example, SCSI defines both.  SCSI can be a hardware bus, bus it also
needs device_class so that scsi_debug (and eventually scsi generic) can
use the struct interface mechanism.

	If you look at the five places where a struct device_class is
actually defined in 2.5.52, you'll see that either the device_class is
not referenced by anything else or it has no bus type.  So, there
seems to be little use of the distinction.

device_class variable   Referenced elsewhere?           bus_type?

cpu_devclass            No                              system_bus_type
memblk_devclass         No                              system_bus_type
node_devclass           No                              system_bus_type
input_devclass          Yes (mousedev, tsdev)           (None)
shost_devclass          Yes (scsi_debug)                (None)

	Also, merging device_class and bus_type could also enable a
little more consolidation between struct device_interface and struct
device_driver (as with device_class.devnum, device_interface.devnum
does not appear to be used currently).

	Anyhow, I think this could shrink the drivers/base a bit and
make it slightly more understandable.  I'd be interested in knowing if
anyone else is contemplating or developing this or wants to point out
issues to watch out for.

Adam J. Richter     __     ______________   575 Oroville Road
[e-mail]     \ /                  Milpitas, California 95035
[phone]         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."