On 22 October 2012 10:29, Julian Elischer <jul...@freebsd.org> wrote:
>> The trouble is going to be handling unplug and kldunload events too. >> Does curvnet -> vnet0 during kldunload events? > > I think in unload events we probably need to cycle through all vnets and > do individual shutdowns of anything that is set up on that vnet.. > (but I'm not reading the code to say that, it's possible to ignore me > safely) Well, in an unload event you know the device you're unloading. However, there may be clones and such involved. It's not like a kldunload will kill a specific VAP on an ath(4) interface, it'll kill the whole interface with all vaps. So in net80211 I need to teach the VAP setup/destroy path to use CURVNET_*() correctly. That's a given. I still however need to ensure that CURVNET_SET(vnet0)/CURVNET_RESTORE() is used around the device attach/detach, as right now the hotplug code doesn't do this. So Marko: * Given that you've "fixed" the kldload path and bootup path to set CURVNET_SET(vnet0) as a special case, how about we teach the device_attach() path to just do this in general? * How does kldunload work right now if any devices are in a vnet? If I kldunload if_bridge with vnets everywhere, what happens? if_bridge doesn't at all know anything about VIMAGE. How do the cloned interfaces get correctly destroyed? I don't want to have to teach _every network device_ that they need to be vnet aware on attach or detach. * the device probe/attach path should just use vnet0; and * the device detach/destroy path, to things like if_free(), should have those functions just use ifp->if_vnet, rather than assuming CURVNET_SET() was called. I know you wanted to be warned if parts of the stack weren't correctly using CURVNET_SET()/CURVNET_RESTORE(), but I think this battle is already lost. :/ Adrian _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"