On Fri, 2007-09-07 at 08:00 +0100, Paul Durrant wrote:
> On 06/09/07, Garrett D'Amore <[EMAIL PROTECTED]> wrote:
> > (Obviously mac_alloc() here would return "mac_t *", but under the covers
> > it is really allocating a whole mac_impl_t. And mac_free() would be
> > free()'ing a a whole mac_impl_t, though it is taking a mac_t as its
> > argument.)
> >
> > If we want to pursue this course of action, I can put together a webrev
> > with the changes... it will take me a while because there are a *lot* of
> > drivers to change... but I want to get this change in *before* we make
> > GLDv3 public.
>
> FWIW, I find the current mac_register_t scheme ugly; I don't see why a
> statically defined mac_register_t cannot simply be passed into
> mac_register(). I don't see why we need separate allocator functions
> there.
> I also don't see that you can't break this race using reference
> counting. There's no need for mac_unregister() to actually free the
> mac_impl_t; it could just drop a ref. and the last man out frees.
> Let's try not to complicate the interface because of implementation
> artifacts.
I think this point has already been hashed over.
One more point. I would prefer adding some complexity to the interface,
if such complexity (maybe a couple extra function calls) can save a
great deal of implementation effort in the consumers of the interface.
(A very narrow interface, that requries a great deal of extra effort to
use due to locking against races, is IMO worse than a slightly broader
interface that has no such requirement.)
In other words, I'm more concerned with complexity and lines of code
added to Nemo drivers than I am with numbers of lines in Nemo header
files, or even numbers of lines in the shared Nemo implementation.
-- Garrett
>
> Paul
>
_______________________________________________
networking-discuss mailing list
[email protected]
