Re: [linux-usb-devel] Re: [RFC] Changes to the driver model class code.

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Tue, 15 Mar 2005 20:08:47 +0100, Dominik Brodowski
<linux@dominikbrodowski.net> wrote:
> On Tue, Mar 15, 2005 at 09:08:34AM -0800, Greg KH wrote:
> > Then I moved the USB host controller code to use this new interface.
> > That was a bit more complex as it used the struct class and struct
> > class_device code directly.  As you can see by the patch, the result is
> > pretty much identical, and actually a bit smaller in the end.
> >
> > So I'll be slowly converting the kernel over to using this new
> > interface, and when finished, I can get rid of the old class apis (or
> > actually, just make them static) so that no one can implement them
> > improperly again...
> >
> > Comments?
> 
> The "old" class api _forced_ you to think of reference counting of
> dynamically allocated objects, while it gets easier to get reference
> counting wrong using this "simple"/"new" interface: while struct class will
> always have fine reference counting, the "parent" struct [with struct class
> no longer being embedded] needs to be thought of individually; and the
> reference count cannot be shared any longer.
> 
> Also, it seems to me that you view the class subsystem to be too closely
> related to /dev entries -- and for these /dev entries class_simple was
> introduced, IIRC. However, /dev is not the reason the class subsystem was
> introduced for -- instead, it describes _types_ of devices which want to
> share (userspace and in-kernel) interfaces.

Exactly! I am working on input_dev class that lies between actual
devices and input class devices exported by evdev, tsdev, etc. It does
not have /dev entry, it is just a building block for the rest of the
subsystem. evdev and the rest will be interfaces (as per driver model)
for the input_dev class and will in turn continue exporting input
class devices that do have /dev entries.

-- 
Dmitry