On Fri, 2007-09-07 at 12:54 -0700, Thirumalai Srinivasan wrote:
> >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" ?
Ah, I misunderstood. I think mac_stop is the intended purpose here...
but by itself, it isn't sufficient to the driver's purposes.
More concisely, mac_stop may be sufficient to provide a guarantee to the
framework that the driver will not upcall (although I'm not sure this is
true today), but it is *not* sufficient to provide a guarantee to the
driver that the framework will not later call mac_start() before
detach(9e) is called.
Note also that if we want to make mac_stop() provide the guarantee to
the framework that no upcalls will happen, then we may have to go
through a bunch of the drivers and make sure that any asynch timeouts
are carefully protected... I think most (all?) of them disable
interrupts, but I'm not sure about cyclics, etc.
On another question, why does the framework need this guarantee?
>
> >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 ?
See above... I think we talking across each other. mac_stop might be
able to achieve that, but it doesn't help the detach() related race.
> 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.
Agreed, but we still need that to solve the original problem that you
pointed out.
>
> >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.
But see, this is where the driver wants to be able to have a simple call
to the nemo framework to say.... please check that its safe for me to go
away, and if you tell me so, then please *guarantee* that it will remain
so.
Synchronization with *detach* requires that the driver be able to
quiesce the mac/framework, not the other way around.
-- Garrett
>
> Thirumalai
>
> _______________________________________________
> networking-discuss mailing list
> [email protected]
_______________________________________________
networking-discuss mailing list
[email protected]
