Garrett D'Amore wrote: > On Tue, 2007-09-04 at 12:45 -0700, Thirumalai Srinivasan wrote: >> Iam not talking about the asynchronous i_mac_notify_thread(), and >> synchronizing that with mac_unregister() is the job of the mac framework. >> >> Iam saying drivers have to ensure that they are pretty much >> single-threaded (with respect to mac calls) while they call >> mac_unregister(). Iam hoping that is already the case today. > > Well, I know at least a couple of drivers that don't obey this rule. > (Every driver I've looked at breaks it... e1000g, bge, eri, hme, rtls, > mxfe, etc.) > > This is one problem with having mac_unregister free the mac_impl_t. > > I think the GLDv2 was better here... it had explicit routines to > allocate and free the soft state, independent of the routines to > register and unregister. For some reason someone decided to get > "clever" with the GLDv3...
We already have mac_alloc() and mac_free() routines. I don't think we should have another free function added to the mix. If we require one mac_alloc() and mac_free() per registered MAC, then it seems we could have them allocate and free the mac_impl_t as well. Instead of invoking mac_free() right after mac_unregister(), the drivers would be required to invoke mac_free() after removing their interrupts and stopping their timers, etc. BTW, I looked at your changes and they look good to me. Nicolas. -- Nicolas Droux - Solaris Core OS - Sun Microsystems, Inc. [EMAIL PROTECTED] - http://blogs.sun.com/droux _______________________________________________ networking-discuss mailing list [email protected]
