> > Moving the radio back to the creators namespace would be the most > > consistent behavior, so I'll check how difficult such a reverse > > lookup is. We then would delete the radio only if it is in the > > creators namespace, or if the creators namespace is gone. Does that > > make sense?
> It does make sense, but it does also feel a bit complicated. Yes, and proper locking gets difficult when using cfg80211_set_netns(), which can sleep. This would probably need larger changes in the locking code, but that's IMO not worth the effort. > Perhaps just special-case the init_net case for consistency with the > existing behaviour, and reserve netgroup 0 for that so we can easily > check for it? I'll do that in a v2, following immediately. > > I suspect you should be defining a structure that currently > > contains one integer member. Something (maybe a compile time > > assert) needs to check that buffer space you are accessing (where > > ever it is) is large enough. > > It does look a bit awkward, but there's no value in having a struct - > you still have an opaque pointer here and cast it to something whose > size you assume to be present... it really makes no difference. I agree there is no added safety when using a struct; Nonetheless have I added one in v2, and is it just for any future member additions. Best regards Martin -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
