On Fri, 2007-09-07 at 10:07 -0400, Sebastien Roy wrote:
> Paul Durrant wrote:
> > Agreed, but you can still do that by the driver exporting a version
> > field in a statically defined structure. The framework just parses the
> > versioned structure and copies relevant fields into the mac_impl_t. No
> > need for the extra function calls.
>
> There is certainly more than one way to build this particular shed.
> There are advantages and disadvantages to both methods. My opinion is
> that allowing incremental additions without having to bump the version
> number is worth a couple of function calls in the driver. The framework
> does not necessitate added complexity of supporting multiple versioned
> structures for backward compatible changes. In the current
> implementation, only incompatible changes need to be handled via
> versioned structures.
Strongly agree.
I don't think a separate mac_register_t was required to achieve this,
though.
As described earlier, I think mac_alloc() could allocate the real
mac_impl_t, and that a "public set of members" (which could have been
protected by using a different structure name... a technique very common
in object-oriented programming) that exposed only those public members.
But right now, the main problem is not allocation, but destruction.
More to the point, the fact that destruction and unregistration are
bound together... for various reasons it is a lot better for everyone if
these can happen at two different points in time, so that drivers can
do:
-> unregistration
-> tear down interrupts, callbacks, etc.
-> destruction
This was how GLDv2 did. I don't understand why anyone felt the need to
redesign this portion of GLDv2.
-- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
