On 09/09/2007, Peter Memishian <[EMAIL PROTECTED]> wrote: > > I presume you mean mac_unregister() above? When I was originally talking > through this problem with Seb (which led to mac_condemn()), my contention > was that the very notion that a destructive operation can fail represents > a design flaw (indeed, we have many of these in Unix -- close(2) being the > most notable). The introduction of mac_condemn() should make it possible > to ensure that mac_unregister() *will* not fail (short of passing it bogus > arguments or other minutia), thus eliminating any need to worry about > undoing partial teardowns. >
The general idea behind mac_unregister() and the fact that it can fail is that it should be the first thing called by a driver's detach(9e) entry point. If it fails the detach() bombs out and nothing further is done. (This is similar to the check that DLPI drivers need to do for open streams, although qattach may have done away with the need for that check). Paul -- Paul Durrant http://www.linkedin.com/in/pdurrant _______________________________________________ networking-discuss mailing list [email protected]
