Re: [RFC] Changes to the driver model class code.
From: Dominik Brodowski
Date: Tue Mar 15 2005 - 15:56:50 EST
On Tue, Mar 15, 2005 at 11:51:21AM -0800, Greg KH wrote:
> > 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.
> I agree, I know it isn't directly related to /dev entries, but that _is_
> the most common usage of it, so I can't ignore it :)
I did not say "ignore". Having the new interface available (patches 1-3)
seems to be a sensible thing to do. Removing the so-called "old" api
(patches 4-x) is a different topic, though.
> Anyway, it's very simple to convert over to using the new functions, and
> still have all of your sysfs and reference counting functionality. See
> the USB patch that I posted in this series as an example of how to do
> this. Just use a kref and a pointer to the class_device. You have all
> of the previous functionality that you needed before right there.
However, you need to do it in _addition_ -- you don't get it "for free" if
using struct class. Which means prgrammers need to think of two things
instead of one. And that's bad(TM).
Also, the lack of proper reference counting in several parts of the kernel
is proof enough that there's need to "encourage" reference counting. And
that's something the class subsystem did and does by providing easy
"embedded" reference counting, by warning on missing !release functions etc.
> class interfaces are not going away, there's a good need for them like
> you have pointed out. I'm not expecting to just delete those api
> functions tomorrow, but slowly phase out the use of them over time, and
> hopefully, eventually get rid of them. I think that with my USB host
> controller patch, I've proved that they are not as needed as you might
> think they were.
Indeed, such _workarounds_ are possible. A patch which converts pcmcia to
this new infrastructure would be quite trivial to write. However: I think we
should NOT do it. As it is a workaround to the more elegant solution the
"old" class API alllowed for.
> It's easy to make a complex, powerful, all-singing-all-dancing api.
> That's what we have today. It's hard to make such an api easy to use,
> that's what we need to realize and start to fix. This is the first of
> such steps to try to achieve this.
Math is hard, so let's go shopping. The "I want a /dev-entry"-api may get
easier with your patches 1-3. With your patch 4 there is no improvement in
this area, however the "I want sane device-related reference counting"-api
will be much more difficult to get right.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/