RFC: bus_type and device_class merge (or partial merge)

RFC: bus_type and device_class merge (or partial merge)

Post by Adam J. Richte » Fri, 20 Dec 2002 21:40:12



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

Quote:};

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

Quote:};

        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

+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

RFC: bus_type and device_class merge (or partial merge)

Post by Patrick Moche » Fri, 20 Dec 2002 23:10:12


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

No, the kernel list is right. I'm a lazy bastard that travels a lot, so
response latency is often higher than it should be.

Quote:>    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.

Someone else tried to do this a while back, and my argument was the same
as this is going to be: they are very distinct objects that describe
different things.

It is true that classes are not used much in the current kernel. The last
six months have not afforded enough time to convert as much code to use
them as I would have preferred. As a result, the class and interface code
is the least mature (and the least personally liked) of the driver model
code.

If you're interested, I've finished a paper for linux.conf.au on the
driver model that should describe the various objects and purposes (much
better than the Ottawa paper did). You can find it at:

http://kernel.org/pub/linux/kernel/people/mochel/doc/lca/driver-model...

Hopefully, you will find it useful. Feel free to send me comments on it,
as it may just be completely crappy.

Quote:>    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.

They're not the same, though. They may be similar, but they are
fundamentally different.

A bus describes a physical transport. It defines semantics for
communicating with resident devices, independent of the functionality they
ultimately serve.

A class is the flipside. It describes the function a device is designed
to perform, independent of its underlying transport.

The interfaces that communicate with devices of a particular class are the
canonical entities that give devices meaning to users and userspace
programs.

Consider audio devices. The only things I care about are /dev/mixer and
/dev/dsp, which map to devices registered with the audio subsystem.
Actually, what is registered are not devices. They are objects allocated
by the driver for my sound card that describe the device in the context of
the audio subsystem. This object is independent of the bus the device
resides on. Communication from userspace to the device passes through the
driver, which formats the class requests to bus and device-specific ones
to actaully talk to the physical device. Something like this:

Me -> device node -> kernel intf -> audio subsys -> driver -> bus -> device

Some buses allow communication to devices on their bus type, regardless of
the devices' function. SCSI does this, as you mention, and so does PCI and
USB, via /proc/bus/*. Functionality is limited to what can generically be
done, and what the bus type allows you to do. They are not classes,
though. The interfaces they correspond to are specific to the underlying
transport.

SCSI is wrong about creating a device class. They are overloading
constructs for their own, twisted purposes. It's partly my fault, as I
know they could use a mechanism for registering and exporting interfaces
to bus-specific devices. It hasn't happened mainly because of time
constraints.

Quote:>    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.

Consolidation is possible, but I would not recommend doing it by merging
the structures. Look for other ways to create common objects that the two
can share. The distinction between the object types is important,
conceptually, if nothing else. Especially during the continuing evolution
of the model. At least for now, and for probably a very long time, I will
not consider patches to consolidate the two object types.

        -pat

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

RFC: bus_type and device_class merge (or partial merge)

Post by Adam J. Richte » Sat, 21 Dec 2002 01:00:14


Quote:>> = Adam Richter
>  = Patrick Mochel
>>       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.

>Someone else tried to do this a while back, and my argument was the same
>as this is going to be: they are very distinct objects that describe
>different things.

        A philosophical musing is not substitute for identifying real
technical advantages or disadvantages, but thanks for the response.

        If my proposed changes shrink kernel memory footprint, improve
code maintainability, allow multiple drivers per device (e.g., scsi
generic and scsi disk), users will be better off with those advantages
than being lost in a doctrine for which they've lost track of the benefits.

        Also, thanks for the pointer to the paper.  I've only skimmed
it at this point, but it at already has helped clarify your thinking
on struct subsystem for me.

Quote:>They're not the same, though. They may be similar, but they are
>fundamentally different.

        There are also differences between USB and PCI, but that
doesn't mean that the part that is handled by drivers/base has to be
different.  The question is whether having separate implementations
for a set of differences make the code smaller, faster, more
functional, or delivers other real benefits that tip the trade-off.

Quote:>A class is the flipside. It describes the function a device is designed
>to perform, independent of its underlying transport.

        You see it as the "flipside" because you're used to seeing
only two levels of indirection (you also haven't shown a real benefit
to a different interface).  Let's look at your example:

Quote:>Consider audio devices. The only things I care about are /dev/mixer and
>/dev/dsp, which map to devices registered with the audio subsystem.
>Actually, what is registered are not devices. They are objects allocated
>by the driver for my sound card that describe the device in the context of
>the audio subsystem. This object is independent of the bus the device
>resides on. Communication from userspace to the device passes through the
>driver, which formats the class requests to bus and device-specific ones
>to actaully talk to the physical device. Something like this:

> Me -> device node -> kernel intf -> audio subsys -> driver -> bus -> device

        Even in this example, there could be many gradations between
bus_type and device_class.  There can be hardware support for complex
sound synthesis and there can be software versions of that same
interface to support more ordinary sound cards.  Sound cards are a
good example of a type of device that can have separate but related
functions, so it may be handy to have device drivers that are written
to accomodate multiple drivers per device (although I would agree that
the _default_ policy should remain only one driver per device at this
point).  The audio hardware may also be located across multiple busses
(PCI --> USB --> USB audio) or may involve more software (PC speaker
driver).

        Perhaps it would help you to understand the impetus that made
me think about this.  I want to have a mechanism for race-free module
unloading without a new lowest level locking primitive (i.e., just by
using rw_semaphore).  To make its use transparent for most cases, I
want add a field to struct device_driver and add a couple of lines to
{,un}register_driver, and I see that if I have to duplicate this
effort if I want the same thing for, say, converting filesystems to
use the generic driver interface.  I don't see that duplication buying
any real improvement in speed, kernel footprint, source code size,
etc.  In other words, having two separate interfaces makes it harder
to write other facilities that are potentially generic to
driver/target rendezvous.

        Anyhow, if you don't convince me of the error of my ways, then
it's probably incumbent upon me to produce a patch before whining
further.

Quote:>Consolidation is possible, but I would not recommend doing it by merging
>the structures. Look for other ways to create common objects that the two
>can share.

        I'm thinking about this.  I just wonder if there would be any
remaining fields that would not be common.

Quote:>The distinction between the object types is important,
>conceptually, if nothing else.

        If it is not important for any other reason, then it's just a
lost opportunity for code shrink and perhaps for potentially making
the facility generically useful in new ways.

Quote:>Especially during the continuing evolution
>of the model. At least for now, and for probably a very long time, I will
>not consider patches to consolidate the two object types.

        Linux will be better if we decide things by weighing technical
benefits rather than by attempts at diktat.  I recommend you keep an
open mind about it.

Adam J. Richter     __     ______________   575 Oroville Road

+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

RFC: bus_type and device_class merge (or partial merge)

Post by Greg K » Sat, 21 Dec 2002 01:50:08



> >> = Adam Richter
> >  = Patrick Mochel

> >Especially during the continuing evolution
> >of the model. At least for now, and for probably a very long time, I will
> >not consider patches to consolidate the two object types.

>    Linux will be better if we decide things by weighing technical
> benefits rather than by attempts at diktat.  I recommend you keep an
> open mind about it.

Heh, if anyone has kept an open mind around here, it's Pat.  Look at the
*that the driver writers have forced him to accommodate.  Here's a
small drawing that some people did at OLS 2002 to help get across how
all of the wide range of busses, classes, devices, and drivers interact
with just one kind of subsystem:
        http://www.veryComputer.com/

The existing code handles monstrosities like that quite well, because he
has kept an open mind, and listened to the driver and subsystem authors.

And yes, we need to start writing more class support, it's next on my
list too.  Patches to do this would be greatly appreciated.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

RFC: bus_type and device_class merge (or partial merge)

Post by Patrick Moche » Sat, 21 Dec 2002 07:10:04


Quote:>    A philosophical musing is not substitute for identifying real
> technical advantages or disadvantages, but thanks for the response.

Ouch.

Quote:>    If my proposed changes shrink kernel memory footprint, improve
> code maintainability, allow multiple drivers per device (e.g., scsi
> generic and scsi disk), users will be better off with those advantages
> than being lost in a doctrine for which they've lost track of the benefits.

You're trying to pinch pennies with the footprint you're talking about.
The extra structure definition costs nothing, and the code to interface
those objects with the other driver model objects is trivial.

Plus, you'd be overloading the object to behave differently depending on
how it was referenced, causing more code. That certainly wouldn't improve
code maintainability.

A device belongs to exactly one bus type and exactly one class type. This
is easy to express. If you combine the objects, you either reference each
instance explicitly, kinda like they are now, or you represent it in some
list, which will complicate the existing code immensely.

What problem would that solve? How would that allow you to bind multiple
drivers to a device? Why would you want to do that anyway?

To support scsi-generic? I've talked with SCSI people before about this.
It's bad to treat it as a driver, because it causes the core to special
case these wacky instances where you have an extension of the bus driver
apply to each device registered with it. I've gotten verbal confirmation
that scsi-generic will change in this regard, and I've offered to provide
hooks to make this easier to express.

For the record, both USB and PCI do similar things. USB creates procfs
entries, and can create device nodes. IIRC, USB makes an explicit call to
the function that does this. PCI makes an explicit call to create procfs
entries for each PCI device. They could all be implemented as 'drivers'
but it doesn't make sense to overload the objects to do it this way.

Quote:> >They're not the same, though. They may be similar, but they are
> >fundamentally different.

>    There are also differences between USB and PCI, but that
> doesn't mean that the part that is handled by drivers/base has to be
> different.  The question is whether having separate implementations
> for a set of differences make the code smaller, faster, more
> functional, or delivers other real benefits that tip the trade-off.

Why? Why try to micro-optimize the core now? You'll gain much more by
converting bus and class drivers to use the driver model objects, and
reducing the replication in the dusty corners of the kernel.

Quote:>    Perhaps it would help you to understand the impetus that made
> me think about this.  I want to have a mechanism for race-free module
> unloading without a new lowest level locking primitive (i.e., just by
> using rw_semaphore).  To make its use transparent for most cases, I
> want add a field to struct device_driver and add a couple of lines to
> {,un}register_driver, and I see that if I have to duplicate this
> effort if I want the same thing for, say, converting filesystems to
> use the generic driver interface.  I don't see that duplication buying
> any real improvement in speed, kernel footprint, source code size,
> etc.  In other words, having two separate interfaces makes it harder
> to write other facilities that are potentially generic to
> driver/target rendezvous.

Fine. That would be nice. You definitely have good intentions, but there
is much more work to be done, that is far less glamorous, that I am
concerned with.

Quote:> >Consolidation is possible, but I would not recommend doing it by merging
> >the structures. Look for other ways to create common objects that the two
> >can share.

>    I'm thinking about this.  I just wonder if there would be any
> remaining fields that would not be common.

Even if there are not, they have different purposes, and different
semantics for dealing with them. Please do not play God on them, they are
there for specific purposes.

Quote:> >Especially during the continuing evolution
> >of the model. At least for now, and for probably a very long time, I will
> >not consider patches to consolidate the two object types.

>    Linux will be better if we decide things by weighing technical
> benefits rather than by attempts at diktat.  I recommend you keep an
> open mind about it.

I like to think I do have an open mind. I listen to what everyone says,
good or bad, and save it all. Well, most. I am definitely not the one to
have a closed mind, since I know for a fact most of the people that rant
and rave have much more experience with this stuff than I do.

I may not respond to everything, and it may appear I ignore things, but
it's only because I am weighing and contemplating them, and their
responses. I may not know the low-level details about many things, but
I've spent enough of the last two years comparing and analyzing the
behavior of drivers to mean it when I say I will not consider patches of
that type. :)

        -pat

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. RFC: bus_type and device_class merge (or partial merge)

        Thanks.  I've read it now.  Here is a proposed patch.  The
only substantive change is a correction to the misunderstanding about
the risk of bus driver modules being unloaded (you might want to
delete the second paragraph that I added).  I've cc'ed linux-kernel
as others might want to comment that proposed change.

        The other changes are just typos and one TeX quirk (apparentlyd
underscores don't have to be escaped in "verbatim" sections).

--
Adam J. Richter     __     ______________   575 Oroville Road

+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

  diffs
6K Download

2. setting up a PPP connection w/Linux PPC 1999 Q3 on a PBG3 WallStreet 1.0

3. Can not save the configuration for SCO Merge's Merge Setup

4. What is PEERDNS?

5. pcmcia: driver_socket as device_class interface [Was: Re: [RFC] pcmcia: bus pcmcia_bus_type, driver_socket as interface]

6. Pine needs libndbm???

7. Merge 4.0/Unixware

8. stupid lilo question

9. Can I merge two files into one?

10. C Code Merge tool

11. kernel merge issues

12. GUIFFY 5.0 compare/merge released

13. Using a 1.2M 5.25" floppy drive with AIX/PS2 and DOS Merge