Mark Lord <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: >> Mark Lord <[EMAIL PROTECTED]> writes: >> >>> Arjan van de Ven wrote: >>>> On Sat, 01 Dec 2007 15:21:12 -0500 >>>> Mark Lord <[EMAIL PROTECTED]> wrote: >>>> >>>>> Eric W. Biederman wrote: >>>>>> Stephen Hemminger <[EMAIL PROTECTED]> writes: >>>>>> Sure. We keep the updated dev_get_by_XXXX that takes a network >>>>>> namespace parameter. >>>>> .. >>>>> >>>>> And what should code be passing in when "# CONFIG_NET_NS is not set" ? >>>> network drivers probably really really don't want to call >>>> dev_get_by_XXX... >>> .. >>> >>> Fine. But all of them want to call sk_alloc(), >> >> network drivers should be calling sk_alloc less then they should >> call dev_get_by_XXXX. Only protocols call sk_alloc. > .. > > I think I saw some bridge code that calls it, too. > Regardless, it's EXPORT_SYMBOL(), but now unusable > due to the GPL-only symbol "init_net". > > Meanwhile, you are avoiding answering the question:
What EXPORT_SYMBOL_GPL means is I don't have a clue how you can use this without being a derivative work of the linux kernel. I think that is true for init_net and I stand by that. It is a very internal symbol. Further the only case that I think might pass the derivative work test would be a network driver, and I am not affecting those. I also believe that since it isn't mandatory you get your struct net pointer by taking the address of a GPL only symbol that those interfaces can continue to be used. However I do suspect you are right that it may be more correct to realized that only a derivative work could possibly use those interfaces and tell 3rd parties that loud and clear. We also have the policy of not changing exports from EXPORT_SYMBOL to EXPORT_SYMBOL_GPL. So making that such a change is difficult. >>>>> And what should code be passing in when "# CONFIG_NET_NS is not set" ? > .. > >>> and many want to do register_netdev(). >> >> I haven't even touched register_netdev. > .. > > Bull-pucky. Somebody did: > >> @@ -3361,6 +3595,8 @@ int register_netdevice(struct net_device *dev) >> >> /* When net_device's are persistent, this will be fatal. */ >> BUG_ON(dev->reg_state != NETREG_UNINITIALIZED); >> + BUG_ON(!dev->nd_net); >> + net = dev->nd_net; >> >> spin_lock_init(&dev->queue_lock); >> spin_lock_init(&dev->_xmit_lock); > .. > > That new BUG_ON() line complains if nd_net has not been initialized, > and the only thing I see drivers putting there is GPL-only "&init_net". Yes and alloc_netdev initializes it. All network drivers are required to call alloc_netdev. So register_netdev from a device driver perspective has not changed. Anything the above change breaks happens to be a broken network device driver. >>> So what should they be using there ? >> >> What are you having problems with? > .. > > Avoiding the question again there, too. No. I am saying that I don't see a problem. All of the real world problems that I actually know of are code bugs. I asked for a real world problem to see if there was something I was missing in my analysis. That isn't avoiding the problem that is trying to see if I was wrong. > I personally am not having problems with anything. > But I noticed the API change, and would like somebody to fix it. > Any of the three ways (or a fourth, if you've got one) might do. Honestly I think I have done the best I can with the knowledge and information that I have. I do not think dropping the GPL from the export of init_net makes sense. I think turning a NULL into init_net is a technical joke. That parameter is there because that is someplace where we need to pay attention to our network namespace. Which only leaves your first option of making more symbols EXPORT_SYMBOL_GPL as even interesting. That would seem to make some sense, given the attitudes and perceptions of the current network developers. However I'm not volunteering for that one as finishing up the network and pid namespaces already has my plate full. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/