Re: [RFC] Changes to the driver model class code.

[Dominik Brodowski]

On Tue, Mar 15, 2005 at 02:14:31PM -0800, Greg KH wrote:
> > So this means every device will have yet another reference count, and you
> > need to be aware of _each_ lifetime to write correct code. And the 
> > _reference counting_ is the hard thing to get right, so we should make 
> > _that_ easier. The existing class API was a step towards this direction, and
> > with the changes you're suggesting here we'd do two jumps backwards.
> 
> You are correct, it was a step forward in this direction.
> 
> But we now have a kref to handle the reference counting for the device,
> which make things a whole lot easier than ever before.

Is it really easier if you have to be aware of _both_ the class reference
possibly having reached zero yet and the kref device reference
possibly having reached zero yet? Using your approach, you need to take 
_two_ lifetimes into account instead of one. Think of class device
attributes being opened / still being accessed when kref device reference 
reaching zero... you need to check for that in code now, AFAICS, while you 
could rely on "we still have a reference to the _device_" in "historic" 
class device attribute access paths.

> But the both of you are correct, there is a real need for the class code
> to support trees of devices that are presented to userspace (which is
> what the class code is for).  I'm not taking that away, just trying to
> make the interface to that code simpler.

The interface may get simpler, but we lose the advantages. And I prefer a
interface which reduces the chances of doing things wrongly; and at least
the existing warnings on empty release functions force you to _think_ about
what you do.

> I'm also not saying that I'm going to go off and delete those functions
> from the kernel today, or tomorrow. 
...
> Anyway, don't worry, the code isn't going away anytime soon,

That's totally besides the point. If the decision was made to indeed do this
transition, I'd be all for doing this fast. If the "old" code was gone
within two weeks, I wouldn't care because of the short period, but because
of the functionality being lost:

> I will not be removing any functionality, don't worry :)

the "functionality" of the device core to teach, encourage, and forcing to 
think of reference counting is being lost by this approach. Independent of
the question whether the transition will take two weeks or two years.

> It will not make the reference counting logic easier to get wrong, or
> easier to get right.  It totally takes it away from the user, and makes
> them implement it themselves if they so wish (like the USB HCD patch
> does.).

Keeping the chance to do the "new"/class_simple way is a good thing -- so
that anybody who _knows_ _exactly_ what he does can shoot himself in his
foot^W^W^W^W^W do what is best for the affected code.

> we just
> need to make it easier to use.  Any suggestions that any of you have to
> make this that way (as you are the ones who had to use it to start with)
> would be greatly appreciated.

	drivers/base/class_simple.c:

	....
	printk("are you really sure you don't want not to have reference counting for free by using struct class instead of struct class_simple *?\n");
	....

:)

Thanks,
	Dominik
-
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/