Garrett D'Amore wrote:
> Heh. This would achieve much the same thing that I was after.
>
> This doesn't do the work to do dls_destroy()... so I'm not entirely sure
> that it is safe. But it *looks* safe to me.
Ah, the missing piece of information is that with Clearview,
dls_destroy() is not done by mac_unregister() (yay!). It's done by the
DACF framework's pre-detach phase prior to the driver calling
mac_unregister() for physical devices. For pseudo devices like aggr and
iptun, it's done by the driver prior to calling mac_unregister() (and
mac_condemn()).
> So, in your gate, if you did the following, it would pretty much achieve
> the same thing I was after:
>
> s/mac_unregister/mac_destroy/ (and assume that it could never fail, so
> maybe cast it to (void).)
In my code, mac_condemn() is optional. mac_unregister() also implicitly
calls mac_condemn() to accommodate drivers which don't have this requirement:
int
mac_unregister(mac_handle_t mh)
{
mac_impl_t *mip = (mac_impl_t *)mh;
mod_hash_val_t val;
mac_multicst_addr_t *p, *nextp;
struct devnames *dnp;
int err;
if ((err = mac_condemn(mh)) != 0)
return (err);
...
The driver can only assume that mac_unregister() can't fail if it has
first successfully called mac_condemn().
>
> s/mac_condemn/mac_unregister/
Yes, that is semantically the same. It depends on your definition of
condemn and unregister. :-) I do like the existing metaphorical symmetry
of register/unregister. Condemn just says, "I'm about to unregister, no
new swimmers in the pool!"
-Seb
_______________________________________________
networking-discuss mailing list
[email protected]
