>It seems a lot of heartache here just to avoid an extra function call in >the drivers. I don't understand the objection to just doing the simple, >and correct, thing of separating out the mac unregistration from the mac >destruction. > Didn't I say
>Separating mac_unregister from mac_destroy is not a big issue, > But that doesn't solve the problem of 'How can the framework quiesce a mac endpoint" ? >For example when all mac clients have closed a mac end point, the >> mac framework would like to quiesce the end point and reclaim / cleanup >> anything associated with that mac endpoint. The last client close -> >> mac_stop() >> -> xxx_m_stop is a point where this synchronization can happen. > > > >I don't think m_stop is the right time to do this, because the GLDv3 >driver still has a reference to the mac_impl_t. > > > If you don't think m_stop is the right mechanism, can you please propose a mechanism by which the framework can quiesce a mac endpoint ? Something that is called only from the driver's detach routine (mac unregister / mac_destroy) is not a good mechanism, since the invocation of the driver's detach routine is not something that the Nemo framework controls. >There is a level of quiesce associated with m_stop, but there is a >secondary level of resource destruction associated with detach. m_stop >does *not* mean that you won't see an m_start happen again almost >instantaneously (in the driver), so its not really a good idea for the >driver to rely too much on m_stop as a quiesce against detatch. > >*UNLESS* there is a guarantee that the framework will not call m_start() >between the time the driver's detach() entry point is called and the >time mac_unregister() completes. Right now I think that there is no >such guarantee. > The Nemo framework can single thread all the xxx_m_* non-data entry points and mac_unregister on a per mac endpoint. The detach entry point is not under the framework's control. Any synchronization with respect to that has to be done by the driver. Thirumalai _______________________________________________ networking-discuss mailing list [email protected]
