On Tue, 8 Oct 2002, Linus Torvalds wrote:
>
> On Tue, 8 Oct 2002, Alexander Viro wrote:
> >
> > Its reference counts mean squat if they are not seen by the code that
> > allocates/frees the object struct device is embedded into.
>
> But Al, that's the whole _point_ of having the callback.
>
> Allow the refcounts to be in an embedded entity, and then anybody who gets
> the entity (_or_ the embedded thing) will increment the same count.
>
> When the count goes to zero, the embedded thing needs to call the
> _embedders_ release function - because the embedded thing doesn't even
> know how it got allocated.
>
> Al, this time you're wrong, and the code you're unhappy about going about
> it the right way. The reference count _has_ to be held by the lowest-level
> thing (because that's the only generic part), yet the actual allocation
> and de-allocation is done by the higher levels. Which is why the lower
> levels need to know which freeing function to call.
That would be nice, if it worked that way. As it is we have
driver allocates foo
driver grabs a reference to foo->dev
....
somebody else grabs/drops temporary references to foo->dev
....
driver call put_device(&foo->dev)
driver frees structures refered from foo.
driver frees foo.
_IF_ the last two steps were done by ->release(), your arguments would
work. Actually they are done by driver right after the put_device() call.
If you are willing to change that (== move all destruction into ->release()) -
yeah, then embedded struct device will work. It's a hell of a work though.
Comments?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:28 EST