Re: namespace support requires network modules to say "GPL"
From: [EMAIL PROTECTED] (Eric W. Biederman) Date: Tue, 04 Dec 2007 12:17:57 -0700 > Ben Greear <[EMAIL PROTECTED]> writes: > > > If I *do* need to add some sort of namespace > > awareness to just achieve today's functionality, I don't mind making the > > changes, > > so long as I don't need to change to GPL licensing. Perhaps at the least > > you > > can export enough symbols w/out GPL tag to achieve backwards compat with .23 > > and previous kernels, or rework dev_get_by_* etc to not need GPL'd namespace > > symbols and just return the device in the default namespace? > > IANAL but to me your code sounds like a derivative work of the linux > kernel. Which implies that if you are distributing your module you > need to change to GPL licensing. The _GPL tag on EXPORT_SYMBOL does > not change those rules. Eric, YANAL and you are also full of hot air. You are really testing my patience on this issue. You fail to ever describe on what factual basis you are making these claims. And the reason is that you have ZERO factual basis for your claims. Here are the facts: 1) Never, ever, have the function for looking up network devices been classified as GPL-only symbols. They provide a device based upon a lookup key. 2) You in no way have changed what those functions do in any way whatsoever. They still provide a reference to a network device based upon a given lookup key. The functions are still doing the same thing they always have. Therefore, you have decided to uniliaterally change the licensing of these functions based solely upon your opinion, and not because of some real change you've made to the code in question. You have no right to do this. This is unreasonable, and you must fix this immediately. And I do mean now, not after you've written several more excessively long diatribes about how you feel in this matter. Thank you. -- 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/
Re: namespace support requires network modules to say "GPL"
From: Ben Greear <[EMAIL PROTECTED]> Date: Tue, 04 Dec 2007 10:57:01 -0800 > echo add_my_bridge my_br1 eth0 namespaceX eth1 namespaceY > > /proc/net/foo/config Each process executes in a namespace, so specifying the namespace is redundant, just fetch the current process's namespace to pass into the dev_get_by_*() routines. Anyone interested in using a different namespace's devices can change the namespace the process is executing in before the procfs echo. -- 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/
Re: namespace support requires network modules to say "GPL"
From: [EMAIL PROTECTED] (Eric W. Biederman) Date: Tue, 04 Dec 2007 11:03:01 -0700 > I am confused. I don't see a path forward that feels right. Eric, instead of writing a book about how you feel, look at the simple facts and resolve this quickly. You added a new key, the namespace, to the looking up of network objects. Big deal. That does not imply a change in licensing for the interfaces where you added that new aspect of the key to the argument list. This symbol licensing decision was not your's to make, so you must revert the new licensing change you are enforcing upon everyone. I want a de-GPL patch in my mailbox from you within the next 24 hours or I will code one up myself. This is getting beyond rediculious. My patience is completely gone on this matter, resolve this now. Thanks. -- 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/
Re: namespace support requires network modules to say "GPL"
Ben Greear <[EMAIL PROTECTED]> writes: > Ok, but can a netdev at least know what namespace it is in? I don't > need this for my module, but it seems very useful knowledge... Sure. dev->nd_net It is a don't care not a don't know, and there should be device events when it goes in and out of a network namespace. I don't know if the device gets those or not. 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/
Re: namespace support requires network modules to say "GPL"
Ben Greear <[EMAIL PROTECTED]> writes: > I have a module that has a collection of 2-port bridges. These bridges are > used > for emulation > purposes (somewhat similar to netem's feature set). Each bridge is logically > independent > of the others. To set up a bridge, I do something like: > > echo add_my_bridge my_br1 eth0 eth1 > /proc/net/foo/config Interesting. Currently /proc/net is also per network namespace. So normally I would say just call get_proc_net from inside your proc handler and all would be well. At another location in /proc (not under /proc/net) I would just do: dev_get_by_name(current->nsproxy->net_ns, "ethX"); I would probably be paranoid and grab current->nsproxy->net_ns when the file was opened and put it when the file was closed just to ensure that if someone opened it and then passed the file descriptor to someone else there were not any weird little races. But I don't expect that is a problem in your case. > Personally, it seems useful for my module to be able to have eth0 in one > namespace > and eth1 in another, but I won't complain if they both have to be in the same > namespace > or even just in the default namespace due to GPL symbol issues. It probably is easiest to move the devices after your module has bridged them. 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/
Re: namespace support requires network modules to say "GPL"
Eric W. Biederman wrote: Ben Greear <[EMAIL PROTECTED]> writes: Eric W. Biederman wrote: However there also seem to be simpler cases like Ben's bridge module, that don't appear to have any global state. Well, my module has some global state, but I don't think it needs to care about namespaces. My first impression is that my module should be able to bridge namespaces...not be contained within one. I can have user-space make sure that I don't bridge between devices in different name-spaces, or perhaps bridging between namespaces wouldn't be a problem anyway. Bridging between namespaces should not be a problem, but it could be a bit of a challenge to setup (in finding the network devices). Probably the easy way is to setup the bridging and then move one of the network devices to the other network namespace. Essentially bridging between two network devices in two network namespaces looks like bridging between two network devices on two separate network stacks. Although internally things look a little better. Ok, that sounds fine. Currently I use procfs and ioctls bound to a procfs file descriptor. Which is where it gets tricky You are defining new userspace ABIs. I can see where they occasionally make sense during development and prototyping but long term out of tree userspace interfaces appear to me to be a real maintenance problem. They are completely contained within my module, and no one is going to change my module w/out me knowing, so actually I have very little problem here :) For namespaces in general, will there be a way to just do a dev_get_by_* and find the device in *any* namespace and query the device to see what namespace it is in? Then my module or some other more clever piece of code can determine the namespaces (by comparing pointers if nothing else) and make proper decision. For instance, maybe we want to bridge two namespaces, or maybe we want to forbid that ever happening... The issue is that fundamentally all userspace device identifiers can be duped between namespaces. So since there is no unique identifier we can not implement a function to do that. Ok, but can a netdev at least know what namespace it is in? I don't need this for my module, but it seems very useful knowledge... Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com -- 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/
Re: namespace support requires network modules to say "GPL"
Ben Greear <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: >> However there also seem to be simpler cases like Ben's bridge module, >> that don't appear to have any global state. >> > Well, my module has some global state, but I don't think it needs to care > about > namespaces. My first impression is that my module should be able to bridge > namespaces...not be contained within one. I can have user-space make sure > that > I don't bridge between > devices in different name-spaces, or perhaps bridging between namespaces > wouldn't be a problem anyway. Bridging between namespaces should not be a problem, but it could be a bit of a challenge to setup (in finding the network devices). Probably the easy way is to setup the bridging and then move one of the network devices to the other network namespace. Essentially bridging between two network devices in two network namespaces looks like bridging between two network devices on two separate network stacks. Although internally things look a little better. > If I *do* need to add some sort of namespace > awareness to just achieve today's functionality, I don't mind making the > changes, > so long as I don't need to change to GPL licensing. Perhaps at the least you > can export enough symbols w/out GPL tag to achieve backwards compat with .23 > and previous kernels, or rework dev_get_by_* etc to not need GPL'd namespace > symbols and just return the device in the default namespace? IANAL but to me your code sounds like a derivative work of the linux kernel. Which implies that if you are distributing your module you need to change to GPL licensing. The _GPL tag on EXPORT_SYMBOL does not change those rules. >> Ben I don't have a clue how your user space interface works. My gut >> feel is that you can likely use sk->sk_net (if your configuration is >> through a socket), or failing that current->nsproxy->net_ns. To get >> the network namespace to look up "eth0" and "eth1". >> > Currently I use procfs and ioctls bound to a procfs file descriptor. Which is where it gets tricky You are defining new userspace ABIs. I can see where they occasionally make sense during development and prototyping but long term out of tree userspace interfaces appear to me to be a real maintenance problem. > For namespaces in general, will there be a way to just do a dev_get_by_* and > find the > device in *any* namespace and query the device to see what namespace it is in? > Then my module or some other more clever piece of code can determine the > namespaces > (by comparing pointers if nothing else) and make proper decision. For > instance, > maybe > we want to bridge two namespaces, or maybe we want to forbid that ever > happening... The issue is that fundamentally all userspace device identifiers can be duped between namespaces. So since there is no unique identifier we can not implement a function to do that. >> This however still begs the question how do we want to handle this >> so there is a minimum of pain. >> >> Since using register_pernet_subsys implies you need your own member >> in struct net. I am inclined to leave that with the GPL hint on >> the EXPORT as you need to be really tight with the system to use that. >> > I certainly don't want to have to muck with struct net unless you have some > way > to > register anonymous (and non GPL) subsystems. I'm guessing you do not want to > support that Well I don't see a license compatible way to have any GPL incompatible licensed linux kernel code. Off hand that means code needs to be licensed under the GPL or BSD without advertising clause. Does EXPORT_SYMBOL_GPL complain if you have a BSD licensed module? 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/
Re: namespace support requires network modules to say "GPL"
Eric W. Biederman wrote: Ben Greear <[EMAIL PROTECTED]> writes: Regardless of infringement it is incompatible with a complete network namespace implementation. Further it sounds like the module you are describing defines a kernel ABI without being merged and hopes that ABI will still be supportable in the future. Honestly I think doing so is horrible code maintenance policy. I don't mind if the ABI changes, so long as I can still use something similar. It has occurred to me that I am seeing an implication here that may in fact not exist. My impression of dev_get_by_ is that the function is only able to be used sanely when being part of the definition of a kernel/userspace interface. With the further assumption on my part that you need to define a new instance of dev_get_by_ It has just occurred to me that it is possible to reuse the SIOCBRADDIF and SIOCBRDELIF for that same purpose without defining a new kernel/userspace interface. What and how are you using dev_get_by_xxx? I have a module that has a collection of 2-port bridges. These bridges are used for emulation purposes (somewhat similar to netem's feature set). Each bridge is logically independent of the others. To set up a bridge, I do something like: echo add_my_bridge my_br1 eth0 eth1 > /proc/net/foo/config Inside the module, it reads "eth0" and "eth1" and needs to find those devices (ie, dev_get_by_name). It then registers to receive all pkts from eth1 and transmit them on eth0, and vice versa. If it would not require GPL symbols, I have no problem changing my API to be something like: echo add_my_bridge my_br1 eth0 namespaceX eth1 namespaceY > /proc/net/foo/config I am using procfs so that I don't have to define any new 'official' kernel ABI, as that would more likely be a derivative work, and is a pain to keep up to date with changing kernels anyway... Personally, it seems useful for my module to be able to have eth0 in one namespace and eth1 in another, but I won't complain if they both have to be in the same namespace or even just in the default namespace due to GPL symbol issues. Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com -- 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/
Re: namespace support requires network modules to say "GPL"
Eric W. Biederman wrote: However there also seem to be simpler cases like Ben's bridge module, that don't appear to have any global state. Well, my module has some global state, but I don't think it needs to care about namespaces. My first impression is that my module should be able to bridge namespaces...not be contained within one. I can have user-space make sure that I don't bridge between devices in different name-spaces, or perhaps bridging between namespaces wouldn't be a problem anyway. If I *do* need to add some sort of namespace awareness to just achieve today's functionality, I don't mind making the changes, so long as I don't need to change to GPL licensing. Perhaps at the least you can export enough symbols w/out GPL tag to achieve backwards compat with .23 and previous kernels, or rework dev_get_by_* etc to not need GPL'd namespace symbols and just return the device in the default namespace? Ben I don't have a clue how your user space interface works. My gut feel is that you can likely use sk->sk_net (if your configuration is through a socket), or failing that current->nsproxy->net_ns. To get the network namespace to look up "eth0" and "eth1". Currently I use procfs and ioctls bound to a procfs file descriptor. For namespaces in general, will there be a way to just do a dev_get_by_* and find the device in *any* namespace and query the device to see what namespace it is in? Then my module or some other more clever piece of code can determine the namespaces (by comparing pointers if nothing else) and make proper decision. For instance, maybe we want to bridge two namespaces, or maybe we want to forbid that ever happening... This however still begs the question how do we want to handle this so there is a minimum of pain. Since using register_pernet_subsys implies you need your own member in struct net. I am inclined to leave that with the GPL hint on the EXPORT as you need to be really tight with the system to use that. I certainly don't want to have to muck with struct net unless you have some way to register anonymous (and non GPL) subsystems. I'm guessing you do not want to support that Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com -- 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/
Re: namespace support requires network modules to say "GPL"
Daniel Lezcano <[EMAIL PROTECTED]> writes: > Ben Greear wrote: >>> Once things are largely complete it makes sense to argue with out of >>> tree module authors that because they don't have network namespace >>> support in their modules, their modules are broken. >> Does this imply that every module that accesses the network code *must* >> become >> GPL simply because it must interact with namespace logic that is exported as >> GPL only symbols? > > That's right, with init_net's EXPORT_SYMBOL_GPL and dev_get_xx, we enforce > people to be GPL whatever they didn't asked to have the namespaces in their > code. > > Eric, why can we simply change EXPORT_SYMBOL_GPL to EXPORT_SYMBOL for > init_net ? Hmm. I need to think this one through. EXPORT_SYMBOL_GPL acts as a strong hint, and a hindrance to using symbols in a non-GPL'd module. Not exactly an enforcement mechanism. ... The current pattern is to first change the code to only work in the initial network namespace. Which can usually be done with a few trivial lines of code that utilize init_net. Then the pattern is to move the globals (or at least a pointer to them) into struct net, and utilize register_pernet_subsys to ensure those variables are properly initialized and cleaned up after. However there also seem to be simpler cases like Ben's bridge module, that don't appear to have any global state. Ben I don't have a clue how your user space interface works. My gut feel is that you can likely use sk->sk_net (if your configuration is through a socket), or failing that current->nsproxy->net_ns. To get the network namespace to look up "eth0" and "eth1". This however still begs the question how do we want to handle this so there is a minimum of pain. Since using register_pernet_subsys implies you need your own member in struct net. I am inclined to leave that with the GPL hint on the EXPORT as you need to be really tight with the system to use that. ... Currently I don't know if the _GPL hint on the export of init_net buys us anything except trouble so I am almost inclined to do something there. What really disturbs me is that as I look at this I see that we have historically at least done a very haphazard job of maintaining our kernel/userspace ABIs while making a commitment to maintain them forever. Especially if as it seems that some would see that commitment extending beyond the code that is ever potentially mergable with the kernel. Currently the only angle that I can see that makes sense to me in the argument for change of how we are currently doing things is that by adding a parameter to new existing functions I make it very difficult for code with network namespace support to have one version that works on both old and new kernels as we can not define the new API on the old hardware. I can see some technical merit in making that case better. . My thinking on the namespaces have been that their interfaces are new core kernel interfaces that have not existed on any other kernel. And as such any code that needed to use those interfaces was: a) definitely a derived work of the kernel. b) was a core part of the kernel, and we don't even want normal day to day drivers using those interfaces much less weird random code outside of the kernel. The above is why I habitually place a _GPL hint on my exports of namespace related functions and data. To strongly suggest to module authors that they are getting into hot water if they use these interfaces and don't merge their code. So far I really don't see anything to challenge my understanding above but I am human and as such my heuristics for analysis and understanding are not guaranteed to give me the right answer. I don't want this to be a stupid political fight about GPL stuff. Generally I am with Alan in not seeing any basis for distributing non-GPL code that works in the kernel. Although I see Linus' point that a legal case may be made that certain modules are not a derivative work of the kernel. ... I am confused. I don't see a path forward that feels right. So I am going to sit and think about this some more, before I do anything. 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/
Re: namespace support requires network modules to say "GPL"
Ben Greear <[EMAIL PROTECTED]> writes: >> Regardless of infringement it is incompatible with a complete network >> namespace implementation. Further it sounds like the module you are >> describing defines a kernel ABI without being merged and hopes that >> ABI will still be supportable in the future. Honestly I think doing so >> is horrible code maintenance policy. >> > I don't mind if the ABI changes, so long as I can still use something similar. It has occurred to me that I am seeing an implication here that may in fact not exist. My impression of dev_get_by_ is that the function is only able to be used sanely when being part of the definition of a kernel/userspace interface. With the further assumption on my part that you need to define a new instance of dev_get_by_ It has just occurred to me that it is possible to reuse the SIOCBRADDIF and SIOCBRDELIF for that same purpose without defining a new kernel/userspace interface. What and how are you using dev_get_by_xxx? 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/
Re: namespace support requires network modules to say "GPL"
Daniel Lezcano wrote: Ben Greear wrote: Eric W. Biederman wrote: Patrick McHardy <[EMAIL PROTECTED]> writes: Ben Greear wrote: I have a binary module that uses dev_get_by_name...it's sort of a bridge-like thing and needs user-space to tell it which device to listen for packets on... This code doesn't need or care about name-spaces, so I don't see how it could really be infringing on the author's code (any worse than loading a binary driver into the kernel ever does). Regardless of infringement it is incompatible with a complete network namespace implementation. Further it sounds like the module you are describing defines a kernel ABI without being merged and hopes that ABI will still be supportable in the future. Honestly I think doing so is horrible code maintenance policy. I don't mind if the ABI changes, so long as I can still use something similar. The namespace logic is interesting to me in general, but at this point I can't think of a way that it actually helps this particular module. All I really need is a way to grab every frame from eth0 and then transmit it to eth1. I'm currently doing this by finding the netdevice and registering a raw-packet protocol (ie, like tcpdump would do). At least up to 2.6.23, this does not require any hacks to the kernel and uses only non GPL exported symbols. Based on my understanding of the namespace logic, if I never add any namespaces, the general network layout should look similar to how it does today, so I should have no logical problem with my module. Once things are largely complete it makes sense to argue with out of tree module authors that because they don't have network namespace support in their modules, their modules are broken. Does this imply that every module that accesses the network code *must* become GPL simply because it must interact with namespace logic that is exported as GPL only symbols? That's right, with init_net's EXPORT_SYMBOL_GPL and dev_get_xx, we enforce people to be GPL whatever they didn't asked to have the namespaces in their code. Eric, why can we simply change EXPORT_SYMBOL_GPL to EXPORT_SYMBOL for init_net ? Another suggestion/question, is it acceptable to say non-gpl driver should use init_task.nsproxy->net_ns instead of _net ? Or does it make sense to have init_net gpl-exported, since we can access it through init_task which is exported without gpl mention ? -- 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/
Re: namespace support requires network modules to say GPL
Daniel Lezcano wrote: Ben Greear wrote: Eric W. Biederman wrote: Patrick McHardy [EMAIL PROTECTED] writes: Ben Greear wrote: I have a binary module that uses dev_get_by_name...it's sort of a bridge-like thing and needs user-space to tell it which device to listen for packets on... This code doesn't need or care about name-spaces, so I don't see how it could really be infringing on the author's code (any worse than loading a binary driver into the kernel ever does). Regardless of infringement it is incompatible with a complete network namespace implementation. Further it sounds like the module you are describing defines a kernel ABI without being merged and hopes that ABI will still be supportable in the future. Honestly I think doing so is horrible code maintenance policy. I don't mind if the ABI changes, so long as I can still use something similar. The namespace logic is interesting to me in general, but at this point I can't think of a way that it actually helps this particular module. All I really need is a way to grab every frame from eth0 and then transmit it to eth1. I'm currently doing this by finding the netdevice and registering a raw-packet protocol (ie, like tcpdump would do). At least up to 2.6.23, this does not require any hacks to the kernel and uses only non GPL exported symbols. Based on my understanding of the namespace logic, if I never add any namespaces, the general network layout should look similar to how it does today, so I should have no logical problem with my module. Once things are largely complete it makes sense to argue with out of tree module authors that because they don't have network namespace support in their modules, their modules are broken. Does this imply that every module that accesses the network code *must* become GPL simply because it must interact with namespace logic that is exported as GPL only symbols? That's right, with init_net's EXPORT_SYMBOL_GPL and dev_get_xx, we enforce people to be GPL whatever they didn't asked to have the namespaces in their code. Eric, why can we simply change EXPORT_SYMBOL_GPL to EXPORT_SYMBOL for init_net ? Another suggestion/question, is it acceptable to say non-gpl driver should use init_task.nsproxy-net_ns instead of init_net ? Or does it make sense to have init_net gpl-exported, since we can access it through init_task which is exported without gpl mention ? -- 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/
Re: namespace support requires network modules to say GPL
Ben Greear [EMAIL PROTECTED] writes: Regardless of infringement it is incompatible with a complete network namespace implementation. Further it sounds like the module you are describing defines a kernel ABI without being merged and hopes that ABI will still be supportable in the future. Honestly I think doing so is horrible code maintenance policy. I don't mind if the ABI changes, so long as I can still use something similar. It has occurred to me that I am seeing an implication here that may in fact not exist. My impression of dev_get_by_ is that the function is only able to be used sanely when being part of the definition of a kernel/userspace interface. With the further assumption on my part that you need to define a new instance of dev_get_by_ It has just occurred to me that it is possible to reuse the SIOCBRADDIF and SIOCBRDELIF for that same purpose without defining a new kernel/userspace interface. What and how are you using dev_get_by_xxx? 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/
Re: namespace support requires network modules to say GPL
Daniel Lezcano [EMAIL PROTECTED] writes: Ben Greear wrote: Once things are largely complete it makes sense to argue with out of tree module authors that because they don't have network namespace support in their modules, their modules are broken. Does this imply that every module that accesses the network code *must* become GPL simply because it must interact with namespace logic that is exported as GPL only symbols? That's right, with init_net's EXPORT_SYMBOL_GPL and dev_get_xx, we enforce people to be GPL whatever they didn't asked to have the namespaces in their code. Eric, why can we simply change EXPORT_SYMBOL_GPL to EXPORT_SYMBOL for init_net ? Hmm. I need to think this one through. EXPORT_SYMBOL_GPL acts as a strong hint, and a hindrance to using symbols in a non-GPL'd module. Not exactly an enforcement mechanism. ... The current pattern is to first change the code to only work in the initial network namespace. Which can usually be done with a few trivial lines of code that utilize init_net. Then the pattern is to move the globals (or at least a pointer to them) into struct net, and utilize register_pernet_subsys to ensure those variables are properly initialized and cleaned up after. However there also seem to be simpler cases like Ben's bridge module, that don't appear to have any global state. Ben I don't have a clue how your user space interface works. My gut feel is that you can likely use sk-sk_net (if your configuration is through a socket), or failing that current-nsproxy-net_ns. To get the network namespace to look up eth0 and eth1. This however still begs the question how do we want to handle this so there is a minimum of pain. Since using register_pernet_subsys implies you need your own member in struct net. I am inclined to leave that with the GPL hint on the EXPORT as you need to be really tight with the system to use that. ... Currently I don't know if the _GPL hint on the export of init_net buys us anything except trouble so I am almost inclined to do something there. What really disturbs me is that as I look at this I see that we have historically at least done a very haphazard job of maintaining our kernel/userspace ABIs while making a commitment to maintain them forever. Especially if as it seems that some would see that commitment extending beyond the code that is ever potentially mergable with the kernel. Currently the only angle that I can see that makes sense to me in the argument for change of how we are currently doing things is that by adding a parameter to new existing functions I make it very difficult for code with network namespace support to have one version that works on both old and new kernels as we can not define the new API on the old hardware. I can see some technical merit in making that case better. . My thinking on the namespaces have been that their interfaces are new core kernel interfaces that have not existed on any other kernel. And as such any code that needed to use those interfaces was: a) definitely a derived work of the kernel. b) was a core part of the kernel, and we don't even want normal day to day drivers using those interfaces much less weird random code outside of the kernel. The above is why I habitually place a _GPL hint on my exports of namespace related functions and data. To strongly suggest to module authors that they are getting into hot water if they use these interfaces and don't merge their code. So far I really don't see anything to challenge my understanding above but I am human and as such my heuristics for analysis and understanding are not guaranteed to give me the right answer. I don't want this to be a stupid political fight about GPL stuff. Generally I am with Alan in not seeing any basis for distributing non-GPL code that works in the kernel. Although I see Linus' point that a legal case may be made that certain modules are not a derivative work of the kernel. ... I am confused. I don't see a path forward that feels right. So I am going to sit and think about this some more, before I do anything. 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/
Re: namespace support requires network modules to say GPL
Eric W. Biederman wrote: However there also seem to be simpler cases like Ben's bridge module, that don't appear to have any global state. Well, my module has some global state, but I don't think it needs to care about namespaces. My first impression is that my module should be able to bridge namespaces...not be contained within one. I can have user-space make sure that I don't bridge between devices in different name-spaces, or perhaps bridging between namespaces wouldn't be a problem anyway. If I *do* need to add some sort of namespace awareness to just achieve today's functionality, I don't mind making the changes, so long as I don't need to change to GPL licensing. Perhaps at the least you can export enough symbols w/out GPL tag to achieve backwards compat with .23 and previous kernels, or rework dev_get_by_* etc to not need GPL'd namespace symbols and just return the device in the default namespace? Ben I don't have a clue how your user space interface works. My gut feel is that you can likely use sk-sk_net (if your configuration is through a socket), or failing that current-nsproxy-net_ns. To get the network namespace to look up eth0 and eth1. Currently I use procfs and ioctls bound to a procfs file descriptor. For namespaces in general, will there be a way to just do a dev_get_by_* and find the device in *any* namespace and query the device to see what namespace it is in? Then my module or some other more clever piece of code can determine the namespaces (by comparing pointers if nothing else) and make proper decision. For instance, maybe we want to bridge two namespaces, or maybe we want to forbid that ever happening... This however still begs the question how do we want to handle this so there is a minimum of pain. Since using register_pernet_subsys implies you need your own member in struct net. I am inclined to leave that with the GPL hint on the EXPORT as you need to be really tight with the system to use that. I certainly don't want to have to muck with struct net unless you have some way to register anonymous (and non GPL) subsystems. I'm guessing you do not want to support that Thanks, Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com -- 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/
Re: namespace support requires network modules to say GPL
Eric W. Biederman wrote: Ben Greear [EMAIL PROTECTED] writes: Regardless of infringement it is incompatible with a complete network namespace implementation. Further it sounds like the module you are describing defines a kernel ABI without being merged and hopes that ABI will still be supportable in the future. Honestly I think doing so is horrible code maintenance policy. I don't mind if the ABI changes, so long as I can still use something similar. It has occurred to me that I am seeing an implication here that may in fact not exist. My impression of dev_get_by_ is that the function is only able to be used sanely when being part of the definition of a kernel/userspace interface. With the further assumption on my part that you need to define a new instance of dev_get_by_ It has just occurred to me that it is possible to reuse the SIOCBRADDIF and SIOCBRDELIF for that same purpose without defining a new kernel/userspace interface. What and how are you using dev_get_by_xxx? I have a module that has a collection of 2-port bridges. These bridges are used for emulation purposes (somewhat similar to netem's feature set). Each bridge is logically independent of the others. To set up a bridge, I do something like: echo add_my_bridge my_br1 eth0 eth1 /proc/net/foo/config Inside the module, it reads eth0 and eth1 and needs to find those devices (ie, dev_get_by_name). It then registers to receive all pkts from eth1 and transmit them on eth0, and vice versa. If it would not require GPL symbols, I have no problem changing my API to be something like: echo add_my_bridge my_br1 eth0 namespaceX eth1 namespaceY /proc/net/foo/config I am using procfs so that I don't have to define any new 'official' kernel ABI, as that would more likely be a derivative work, and is a pain to keep up to date with changing kernels anyway... Personally, it seems useful for my module to be able to have eth0 in one namespace and eth1 in another, but I won't complain if they both have to be in the same namespace or even just in the default namespace due to GPL symbol issues. Thanks, Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com -- 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/
Re: namespace support requires network modules to say GPL
Ben Greear [EMAIL PROTECTED] writes: Eric W. Biederman wrote: However there also seem to be simpler cases like Ben's bridge module, that don't appear to have any global state. Well, my module has some global state, but I don't think it needs to care about namespaces. My first impression is that my module should be able to bridge namespaces...not be contained within one. I can have user-space make sure that I don't bridge between devices in different name-spaces, or perhaps bridging between namespaces wouldn't be a problem anyway. Bridging between namespaces should not be a problem, but it could be a bit of a challenge to setup (in finding the network devices). Probably the easy way is to setup the bridging and then move one of the network devices to the other network namespace. Essentially bridging between two network devices in two network namespaces looks like bridging between two network devices on two separate network stacks. Although internally things look a little better. If I *do* need to add some sort of namespace awareness to just achieve today's functionality, I don't mind making the changes, so long as I don't need to change to GPL licensing. Perhaps at the least you can export enough symbols w/out GPL tag to achieve backwards compat with .23 and previous kernels, or rework dev_get_by_* etc to not need GPL'd namespace symbols and just return the device in the default namespace? IANAL but to me your code sounds like a derivative work of the linux kernel. Which implies that if you are distributing your module you need to change to GPL licensing. The _GPL tag on EXPORT_SYMBOL does not change those rules. Ben I don't have a clue how your user space interface works. My gut feel is that you can likely use sk-sk_net (if your configuration is through a socket), or failing that current-nsproxy-net_ns. To get the network namespace to look up eth0 and eth1. Currently I use procfs and ioctls bound to a procfs file descriptor. Which is where it gets tricky You are defining new userspace ABIs. I can see where they occasionally make sense during development and prototyping but long term out of tree userspace interfaces appear to me to be a real maintenance problem. For namespaces in general, will there be a way to just do a dev_get_by_* and find the device in *any* namespace and query the device to see what namespace it is in? Then my module or some other more clever piece of code can determine the namespaces (by comparing pointers if nothing else) and make proper decision. For instance, maybe we want to bridge two namespaces, or maybe we want to forbid that ever happening... The issue is that fundamentally all userspace device identifiers can be duped between namespaces. So since there is no unique identifier we can not implement a function to do that. This however still begs the question how do we want to handle this so there is a minimum of pain. Since using register_pernet_subsys implies you need your own member in struct net. I am inclined to leave that with the GPL hint on the EXPORT as you need to be really tight with the system to use that. I certainly don't want to have to muck with struct net unless you have some way to register anonymous (and non GPL) subsystems. I'm guessing you do not want to support that Well I don't see a license compatible way to have any GPL incompatible licensed linux kernel code. Off hand that means code needs to be licensed under the GPL or BSD without advertising clause. Does EXPORT_SYMBOL_GPL complain if you have a BSD licensed module? 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/
Re: namespace support requires network modules to say GPL
Eric W. Biederman wrote: Ben Greear [EMAIL PROTECTED] writes: Eric W. Biederman wrote: However there also seem to be simpler cases like Ben's bridge module, that don't appear to have any global state. Well, my module has some global state, but I don't think it needs to care about namespaces. My first impression is that my module should be able to bridge namespaces...not be contained within one. I can have user-space make sure that I don't bridge between devices in different name-spaces, or perhaps bridging between namespaces wouldn't be a problem anyway. Bridging between namespaces should not be a problem, but it could be a bit of a challenge to setup (in finding the network devices). Probably the easy way is to setup the bridging and then move one of the network devices to the other network namespace. Essentially bridging between two network devices in two network namespaces looks like bridging between two network devices on two separate network stacks. Although internally things look a little better. Ok, that sounds fine. Currently I use procfs and ioctls bound to a procfs file descriptor. Which is where it gets tricky You are defining new userspace ABIs. I can see where they occasionally make sense during development and prototyping but long term out of tree userspace interfaces appear to me to be a real maintenance problem. They are completely contained within my module, and no one is going to change my module w/out me knowing, so actually I have very little problem here :) For namespaces in general, will there be a way to just do a dev_get_by_* and find the device in *any* namespace and query the device to see what namespace it is in? Then my module or some other more clever piece of code can determine the namespaces (by comparing pointers if nothing else) and make proper decision. For instance, maybe we want to bridge two namespaces, or maybe we want to forbid that ever happening... The issue is that fundamentally all userspace device identifiers can be duped between namespaces. So since there is no unique identifier we can not implement a function to do that. Ok, but can a netdev at least know what namespace it is in? I don't need this for my module, but it seems very useful knowledge... Thanks, Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com -- 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/
Re: namespace support requires network modules to say GPL
Ben Greear [EMAIL PROTECTED] writes: I have a module that has a collection of 2-port bridges. These bridges are used for emulation purposes (somewhat similar to netem's feature set). Each bridge is logically independent of the others. To set up a bridge, I do something like: echo add_my_bridge my_br1 eth0 eth1 /proc/net/foo/config Interesting. Currently /proc/net is also per network namespace. So normally I would say just call get_proc_net from inside your proc handler and all would be well. At another location in /proc (not under /proc/net) I would just do: dev_get_by_name(current-nsproxy-net_ns, ethX); I would probably be paranoid and grab current-nsproxy-net_ns when the file was opened and put it when the file was closed just to ensure that if someone opened it and then passed the file descriptor to someone else there were not any weird little races. But I don't expect that is a problem in your case. Personally, it seems useful for my module to be able to have eth0 in one namespace and eth1 in another, but I won't complain if they both have to be in the same namespace or even just in the default namespace due to GPL symbol issues. It probably is easiest to move the devices after your module has bridged them. 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/
Re: namespace support requires network modules to say GPL
Ben Greear [EMAIL PROTECTED] writes: Ok, but can a netdev at least know what namespace it is in? I don't need this for my module, but it seems very useful knowledge... Sure. dev-nd_net It is a don't care not a don't know, and there should be device events when it goes in and out of a network namespace. I don't know if the device gets those or not. 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/
Re: namespace support requires network modules to say GPL
From: Ben Greear [EMAIL PROTECTED] Date: Tue, 04 Dec 2007 10:57:01 -0800 echo add_my_bridge my_br1 eth0 namespaceX eth1 namespaceY /proc/net/foo/config Each process executes in a namespace, so specifying the namespace is redundant, just fetch the current process's namespace to pass into the dev_get_by_*() routines. Anyone interested in using a different namespace's devices can change the namespace the process is executing in before the procfs echo. -- 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/
Re: namespace support requires network modules to say GPL
From: [EMAIL PROTECTED] (Eric W. Biederman) Date: Tue, 04 Dec 2007 11:03:01 -0700 I am confused. I don't see a path forward that feels right. Eric, instead of writing a book about how you feel, look at the simple facts and resolve this quickly. You added a new key, the namespace, to the looking up of network objects. Big deal. That does not imply a change in licensing for the interfaces where you added that new aspect of the key to the argument list. This symbol licensing decision was not your's to make, so you must revert the new licensing change you are enforcing upon everyone. I want a de-GPL patch in my mailbox from you within the next 24 hours or I will code one up myself. This is getting beyond rediculious. My patience is completely gone on this matter, resolve this now. Thanks. -- 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/
Re: namespace support requires network modules to say GPL
From: [EMAIL PROTECTED] (Eric W. Biederman) Date: Tue, 04 Dec 2007 12:17:57 -0700 Ben Greear [EMAIL PROTECTED] writes: If I *do* need to add some sort of namespace awareness to just achieve today's functionality, I don't mind making the changes, so long as I don't need to change to GPL licensing. Perhaps at the least you can export enough symbols w/out GPL tag to achieve backwards compat with .23 and previous kernels, or rework dev_get_by_* etc to not need GPL'd namespace symbols and just return the device in the default namespace? IANAL but to me your code sounds like a derivative work of the linux kernel. Which implies that if you are distributing your module you need to change to GPL licensing. The _GPL tag on EXPORT_SYMBOL does not change those rules. Eric, YANAL and you are also full of hot air. You are really testing my patience on this issue. You fail to ever describe on what factual basis you are making these claims. And the reason is that you have ZERO factual basis for your claims. Here are the facts: 1) Never, ever, have the function for looking up network devices been classified as GPL-only symbols. They provide a device based upon a lookup key. 2) You in no way have changed what those functions do in any way whatsoever. They still provide a reference to a network device based upon a given lookup key. The functions are still doing the same thing they always have. Therefore, you have decided to uniliaterally change the licensing of these functions based solely upon your opinion, and not because of some real change you've made to the code in question. You have no right to do this. This is unreasonable, and you must fix this immediately. And I do mean now, not after you've written several more excessively long diatribes about how you feel in this matter. Thank you. -- 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/
Re: namespace support requires network modules to say "GPL"
Ben Greear wrote: Eric W. Biederman wrote: Patrick McHardy <[EMAIL PROTECTED]> writes: Ben Greear wrote: I have a binary module that uses dev_get_by_name...it's sort of a bridge-like thing and needs user-space to tell it which device to listen for packets on... This code doesn't need or care about name-spaces, so I don't see how it could really be infringing on the author's code (any worse than loading a binary driver into the kernel ever does). Regardless of infringement it is incompatible with a complete network namespace implementation. Further it sounds like the module you are describing defines a kernel ABI without being merged and hopes that ABI will still be supportable in the future. Honestly I think doing so is horrible code maintenance policy. I don't mind if the ABI changes, so long as I can still use something similar. The namespace logic is interesting to me in general, but at this point I can't think of a way that it actually helps this particular module. All I really need is a way to grab every frame from eth0 and then transmit it to eth1. I'm currently doing this by finding the netdevice and registering a raw-packet protocol (ie, like tcpdump would do). At least up to 2.6.23, this does not require any hacks to the kernel and uses only non GPL exported symbols. Based on my understanding of the namespace logic, if I never add any namespaces, the general network layout should look similar to how it does today, so I should have no logical problem with my module. Once things are largely complete it makes sense to argue with out of tree module authors that because they don't have network namespace support in their modules, their modules are broken. Does this imply that every module that accesses the network code *must* become GPL simply because it must interact with namespace logic that is exported as GPL only symbols? That's right, with init_net's EXPORT_SYMBOL_GPL and dev_get_xx, we enforce people to be GPL whatever they didn't asked to have the namespaces in their code. Eric, why can we simply change EXPORT_SYMBOL_GPL to EXPORT_SYMBOL for init_net ? -- 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/
Re: namespace support requires network modules to say "GPL"
Eric W. Biederman wrote: Patrick McHardy <[EMAIL PROTECTED]> writes: Ben Greear wrote: I have a binary module that uses dev_get_by_name...it's sort of a bridge-like thing and needs user-space to tell it which device to listen for packets on... This code doesn't need or care about name-spaces, so I don't see how it could really be infringing on the author's code (any worse than loading a binary driver into the kernel ever does). Regardless of infringement it is incompatible with a complete network namespace implementation. Further it sounds like the module you are describing defines a kernel ABI without being merged and hopes that ABI will still be supportable in the future. Honestly I think doing so is horrible code maintenance policy. I don't mind if the ABI changes, so long as I can still use something similar. The namespace logic is interesting to me in general, but at this point I can't think of a way that it actually helps this particular module. All I really need is a way to grab every frame from eth0 and then transmit it to eth1. I'm currently doing this by finding the netdevice and registering a raw-packet protocol (ie, like tcpdump would do). At least up to 2.6.23, this does not require any hacks to the kernel and uses only non GPL exported symbols. Based on my understanding of the namespace logic, if I never add any namespaces, the general network layout should look similar to how it does today, so I should have no logical problem with my module. Once things are largely complete it makes sense to argue with out of tree module authors that because they don't have network namespace support in their modules, their modules are broken. Does this imply that every module that accesses the network code *must* become GPL simply because it must interact with namespace logic that is exported as GPL only symbols? Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com -- 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/
Re: namespace support requires network modules to say "GPL"
From: [EMAIL PROTECTED] (Eric W. Biederman) Date: Mon, 03 Dec 2007 11:03:38 -0700 > Based on my experience with in-tree code and the few glimpses I > have gotten of out of tree code the reason the out of tree code broke > is because it is doing very questionable things. Calling dev_get_by_foo() was never ever a very questionable thing. Stop saying bullshit, because that's all that is coming out of your mouth in this thread. The fact is, these modules called perfectly fine interfaces and by adding namespaces YOU BROKE THEM. That by itself is OK, they can make the code changes to adapt and use the init namespace. Enforcing new licensing restrictions on them for existing interfaces just because you add a new freaking argument that is practically speaking a constant and always the same right now, on the other hand, IS NOT FINE and you must fix this now. I don't care how you do it. If you don't want them to get at the init namespace symbol, fine, revert all the dev_get_by_*() interfaces to not take the namespace symbol and make them internally use the init namespace albeit invisibly to the caller. Then you make all the existing call sites invoke new dev_get_by_*_ns() interfaces that take an explicit argument. But only do this where it is truly necessary, everything uses the init namespace practically speaking and it's clearer if you conver to the *_ns() variant when the code itself is converted. -- 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/
Re: namespace support requires network modules to say "GPL"
Romano Giannetti <[EMAIL PROTECTED]> writes: > Please pardon me for jumping in; I am not a kernel developer, but I try > to help with debugging whenever I can (and it's not just hand-waving, I > helped to track down a couple of nasty bugs on MMC or ACPI EC, > recently). And I am an engineer and IANAL, so I wouldn't speak about > laws here. But I think it's not just a distribution's problem. > > Unfortunately, I need VMware and ndiswrapper to get work done with my > laptop. It's not the perfect world, but the only alternative is to boot > in XP. So I normally stick with vendors kernels and, when I have time to > "play" with new kernel, I go for it. If ndiswrapper and VMware work, > perfect, I can test extensively the new kernel; if I find problems, I > *know* I have to restart without proprietary modules, try to reproduce, > report back. I did it a lot of times. > > What I think is that every time VMware or (worst) ndiswrapper breaks, > the kernel loose an awful lot of testers. In the span of time before > Giri and the VMware team post a patch (-rc1 and -rc4, tipically), my > testing activity is just occasional. And I guess a lot of people is in > the same situation. > > These are just my 2cents. I will continue to test new kernels every time > I can, and to use native solutions as often as I can (go, ath5k, go!; > and LabWindows/CVI for Linux, anyone?). But maybe a bit of tolerance can > help everyone... As a kernel developer let me say thank you for doing what testing you can. I think a bit of tolerance for others can help the conversation. At the same time since out of tree modules (even GPL'd ones) have not chosen to play with us we have to move forward as best we can without their input. It isn't possible to do anything else. Right now I have made some changes for good technical reasons, and some out of tree modules have broken. Regardless of the flavor of EXPORT_SYMBOL they would have broken. Based on my experience with in-tree code and the few glimpses I have gotten of out of tree code the reason the out of tree code broke is because it is doing very questionable things. So the best I can say at this point, is my apologies that we have not served you better and made it possible to do what you need to do without relying on code of questionable character. Hopefully this situation will be better in the future. 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/
Re: namespace support requires network modules to say "GPL"
Patrick McHardy <[EMAIL PROTECTED]> writes: > Ben Greear wrote: >> I have a binary module that uses dev_get_by_name...it's sort of a bridge-like >> thing and >> needs user-space to tell it which device to listen for packets on... >> >> This code doesn't need or care about name-spaces, so I don't see how it could >> really >> be infringing on the author's code (any worse than loading a binary driver >> into the kernel >> ever does). Regardless of infringement it is incompatible with a complete network namespace implementation. Further it sounds like the module you are describing defines a kernel ABI without being merged and hopes that ABI will still be supportable in the future. Honestly I think doing so is horrible code maintenance policy. >> I would certainly prefer to not have to patch around any problems with >> calling >> dev_get_by_name >> from a non-gpl module, but if required, I can probably figure something >> out... > > > For all I care binary modules can break, but frankly I don't see > how encapsulating a couple of structures and pointers in a new > structure and adding a new argument to existing functions shifts > the decision about how a function should be usable to the namespace > guys. IMO all functions should continue to be usable as before, > as decided by whoever actually wrote them. The only exception > might be stuff where an existing EXPORT_SYMBOL is clearly wrong, > but that would be a seperate discussion. I don't think we have actually shifted the decision. Further from a namespace perspective if I had to support out of tree modules and the current in kernel API the implementation would be impossible short of loading kernel modules multiple times once for each namespace. I totally refuse to give out of tree modules that power whatever their license. Right now the network namespace code that has been merged isn't that interesting as it does not include ipv4 and ipv6 support which everyone uses. One of the tests for completion of the network namespace work is grepping for _net and making certain we have cleanly removed all references to except in a handful of cases like the boot code. Once things are largely complete it makes sense to argue with out of tree module authors that because they don't have network namespace support in their modules, their modules are broken. Right now I suspect to many developers even of in-tree modules I have just shifted code around in an annoying looking way. I can completely see other developers not getting the point. 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/
Re: namespace support requires network modules to say "GPL"
On Mon, 03 Dec 2007 09:24:15 +0100 Romano Giannetti <[EMAIL PROTECTED]> wrote: > > > On Sat, 2007-12-01 at 22:34 -0500, Mark Lord wrote: > > Stephen Hemminger wrote:. > > >> > > > I spoke too soon earlier, ndiswrapper builds and loads against > > > current 2.6.24-rc3. Vmware and proprietary VPN software probably > > > do not. Once again I don't give a damn, but the enterprise distro > > > vendors certainly care. > > ... > > > > Naw, enterprise (or any other) distro vendors shouldn't have any > > issues here, since they can just patch their kernels around any > > issues. > > Please pardon me for jumping in; > > What I think is that every time VMware or (worst) ndiswrapper breaks, if you had read the thread... ndiswrapper doesn't break, and vmware driver had some bugs that, once fixed, no no longer break either -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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/
Re: namespace support requires network modules to say "GPL"
Patrick McHardy wrote: > Adrian Bunk wrote: >> On Sun, Dec 02, 2007 at 09:03:56PM +0100, Patrick McHardy wrote: >> >>> For all I care binary modules can break, but frankly I don't see >>> how encapsulating a couple of structures and pointers in a new >>> structure and adding a new argument to existing functions shifts >>> the decision about how a function should be usable to the namespace >>> guys. IMO all functions should continue to be usable as before, >>> as decided by whoever actually wrote them. >>> ... >> >> Even ignoring the fact that it's unclear whether distributing modules >> with not GPLv2 compatible licences is legal at all or might bring you >> in jail, > > Agreed, lets ignore that :) > >> your statement has an interesting implication: >> >> Stuff like e.g. the EXPORT_SYMBOL(sk_alloc) predates the >> EXPORT_SYMBOL_GPL stuff. >> >> Who is considered the author of this code? >> >> And when should he state whether he prefers to use EXPORT_SYMBOL_GPL >> but wasn't able to use it at that when he wrote it since his code >> predates it and is glad to be able to decide this now? > > > He can state it when he feels like it, I don't see the point. > Authors generally get to decide whether they use EXPORT_SYMBOL > or EXPORT_SYMBOL_GPL unless in cases where its really clear-cut > that EXPORT_SYMBOL is inapproriate. But thats a different matter. > > If a symbol was OK to be used previously and something using it > would not automatically be considered a derived work, how does > passing _net to the function just to make the compiler > happy, avoid BUG_ONs and generally keep things working as before > make it more of a derived work? We, namely, Pavel Emelyanov and me, if we have some rights as a committers to this staff :), do not mind against change EXPORT_SYMBOL_GPL to EXPORT_SYMBOL. Regards, Den -- 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/
Re: namespace support requires network modules to say "GPL"
On Sat, 2007-12-01 at 22:34 -0500, Mark Lord wrote: > Stephen Hemminger wrote:. > >> > > I spoke too soon earlier, ndiswrapper builds and loads against current > > 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again > > I don't > > give a damn, but the enterprise distro vendors certainly care. > ... > > Naw, enterprise (or any other) distro vendors shouldn't have any issues here, > since they can just patch their kernels around any issues. Please pardon me for jumping in; I am not a kernel developer, but I try to help with debugging whenever I can (and it's not just hand-waving, I helped to track down a couple of nasty bugs on MMC or ACPI EC, recently). And I am an engineer and IANAL, so I wouldn't speak about laws here. But I think it's not just a distribution's problem. Unfortunately, I need VMware and ndiswrapper to get work done with my laptop. It's not the perfect world, but the only alternative is to boot in XP. So I normally stick with vendors kernels and, when I have time to "play" with new kernel, I go for it. If ndiswrapper and VMware work, perfect, I can test extensively the new kernel; if I find problems, I *know* I have to restart without proprietary modules, try to reproduce, report back. I did it a lot of times. What I think is that every time VMware or (worst) ndiswrapper breaks, the kernel loose an awful lot of testers. In the span of time before Giri and the VMware team post a patch (-rc1 and -rc4, tipically), my testing activity is just occasional. And I guess a lot of people is in the same situation. These are just my 2cents. I will continue to test new kernels every time I can, and to use native solutions as often as I can (go, ath5k, go!; and LabWindows/CVI for Linux, anyone?). But maybe a bit of tolerance can help everyone... Back in my hole, Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifÃquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. -- 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/
Re: namespace support requires network modules to say GPL
Patrick McHardy wrote: Adrian Bunk wrote: On Sun, Dec 02, 2007 at 09:03:56PM +0100, Patrick McHardy wrote: For all I care binary modules can break, but frankly I don't see how encapsulating a couple of structures and pointers in a new structure and adding a new argument to existing functions shifts the decision about how a function should be usable to the namespace guys. IMO all functions should continue to be usable as before, as decided by whoever actually wrote them. ... Even ignoring the fact that it's unclear whether distributing modules with not GPLv2 compatible licences is legal at all or might bring you in jail, Agreed, lets ignore that :) your statement has an interesting implication: Stuff like e.g. the EXPORT_SYMBOL(sk_alloc) predates the EXPORT_SYMBOL_GPL stuff. Who is considered the author of this code? And when should he state whether he prefers to use EXPORT_SYMBOL_GPL but wasn't able to use it at that when he wrote it since his code predates it and is glad to be able to decide this now? He can state it when he feels like it, I don't see the point. Authors generally get to decide whether they use EXPORT_SYMBOL or EXPORT_SYMBOL_GPL unless in cases where its really clear-cut that EXPORT_SYMBOL is inapproriate. But thats a different matter. If a symbol was OK to be used previously and something using it would not automatically be considered a derived work, how does passing init_net to the function just to make the compiler happy, avoid BUG_ONs and generally keep things working as before make it more of a derived work? We, namely, Pavel Emelyanov and me, if we have some rights as a committers to this staff :), do not mind against change EXPORT_SYMBOL_GPL to EXPORT_SYMBOL. Regards, Den -- 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/
Re: namespace support requires network modules to say GPL
On Sat, 2007-12-01 at 22:34 -0500, Mark Lord wrote: Stephen Hemminger wrote:. I spoke too soon earlier, ndiswrapper builds and loads against current 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again I don't give a damn, but the enterprise distro vendors certainly care. ... Naw, enterprise (or any other) distro vendors shouldn't have any issues here, since they can just patch their kernels around any issues. Please pardon me for jumping in; I am not a kernel developer, but I try to help with debugging whenever I can (and it's not just hand-waving, I helped to track down a couple of nasty bugs on MMC or ACPI EC, recently). And I am an engineer and IANAL, so I wouldn't speak about laws here. But I think it's not just a distribution's problem. Unfortunately, I need VMware and ndiswrapper to get work done with my laptop. It's not the perfect world, but the only alternative is to boot in XP. So I normally stick with vendors kernels and, when I have time to play with new kernel, I go for it. If ndiswrapper and VMware work, perfect, I can test extensively the new kernel; if I find problems, I *know* I have to restart without proprietary modules, try to reproduce, report back. I did it a lot of times. What I think is that every time VMware or (worst) ndiswrapper breaks, the kernel loose an awful lot of testers. In the span of time before Giri and the VMware team post a patch (-rc1 and -rc4, tipically), my testing activity is just occasional. And I guess a lot of people is in the same situation. These are just my 2cents. I will continue to test new kernels every time I can, and to use native solutions as often as I can (go, ath5k, go!; and LabWindows/CVI for Linux, anyone?). But maybe a bit of tolerance can help everyone... Back in my hole, Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifÃquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. -- 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/
Re: namespace support requires network modules to say GPL
On Mon, 03 Dec 2007 09:24:15 +0100 Romano Giannetti [EMAIL PROTECTED] wrote: On Sat, 2007-12-01 at 22:34 -0500, Mark Lord wrote: Stephen Hemminger wrote:. I spoke too soon earlier, ndiswrapper builds and loads against current 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again I don't give a damn, but the enterprise distro vendors certainly care. ... Naw, enterprise (or any other) distro vendors shouldn't have any issues here, since they can just patch their kernels around any issues. Please pardon me for jumping in; What I think is that every time VMware or (worst) ndiswrapper breaks, if you had read the thread... ndiswrapper doesn't break, and vmware driver had some bugs that, once fixed, no no longer break either -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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/
Re: namespace support requires network modules to say GPL
Patrick McHardy [EMAIL PROTECTED] writes: Ben Greear wrote: I have a binary module that uses dev_get_by_name...it's sort of a bridge-like thing and needs user-space to tell it which device to listen for packets on... This code doesn't need or care about name-spaces, so I don't see how it could really be infringing on the author's code (any worse than loading a binary driver into the kernel ever does). Regardless of infringement it is incompatible with a complete network namespace implementation. Further it sounds like the module you are describing defines a kernel ABI without being merged and hopes that ABI will still be supportable in the future. Honestly I think doing so is horrible code maintenance policy. I would certainly prefer to not have to patch around any problems with calling dev_get_by_name from a non-gpl module, but if required, I can probably figure something out... For all I care binary modules can break, but frankly I don't see how encapsulating a couple of structures and pointers in a new structure and adding a new argument to existing functions shifts the decision about how a function should be usable to the namespace guys. IMO all functions should continue to be usable as before, as decided by whoever actually wrote them. The only exception might be stuff where an existing EXPORT_SYMBOL is clearly wrong, but that would be a seperate discussion. I don't think we have actually shifted the decision. Further from a namespace perspective if I had to support out of tree modules and the current in kernel API the implementation would be impossible short of loading kernel modules multiple times once for each namespace. I totally refuse to give out of tree modules that power whatever their license. Right now the network namespace code that has been merged isn't that interesting as it does not include ipv4 and ipv6 support which everyone uses. One of the tests for completion of the network namespace work is grepping for init_net and making certain we have cleanly removed all references to except in a handful of cases like the boot code. Once things are largely complete it makes sense to argue with out of tree module authors that because they don't have network namespace support in their modules, their modules are broken. Right now I suspect to many developers even of in-tree modules I have just shifted code around in an annoying looking way. I can completely see other developers not getting the point. 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/
Re: namespace support requires network modules to say GPL
Romano Giannetti [EMAIL PROTECTED] writes: Please pardon me for jumping in; I am not a kernel developer, but I try to help with debugging whenever I can (and it's not just hand-waving, I helped to track down a couple of nasty bugs on MMC or ACPI EC, recently). And I am an engineer and IANAL, so I wouldn't speak about laws here. But I think it's not just a distribution's problem. Unfortunately, I need VMware and ndiswrapper to get work done with my laptop. It's not the perfect world, but the only alternative is to boot in XP. So I normally stick with vendors kernels and, when I have time to play with new kernel, I go for it. If ndiswrapper and VMware work, perfect, I can test extensively the new kernel; if I find problems, I *know* I have to restart without proprietary modules, try to reproduce, report back. I did it a lot of times. What I think is that every time VMware or (worst) ndiswrapper breaks, the kernel loose an awful lot of testers. In the span of time before Giri and the VMware team post a patch (-rc1 and -rc4, tipically), my testing activity is just occasional. And I guess a lot of people is in the same situation. These are just my 2cents. I will continue to test new kernels every time I can, and to use native solutions as often as I can (go, ath5k, go!; and LabWindows/CVI for Linux, anyone?). But maybe a bit of tolerance can help everyone... As a kernel developer let me say thank you for doing what testing you can. I think a bit of tolerance for others can help the conversation. At the same time since out of tree modules (even GPL'd ones) have not chosen to play with us we have to move forward as best we can without their input. It isn't possible to do anything else. Right now I have made some changes for good technical reasons, and some out of tree modules have broken. Regardless of the flavor of EXPORT_SYMBOL they would have broken. Based on my experience with in-tree code and the few glimpses I have gotten of out of tree code the reason the out of tree code broke is because it is doing very questionable things. So the best I can say at this point, is my apologies that we have not served you better and made it possible to do what you need to do without relying on code of questionable character. Hopefully this situation will be better in the future. 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/
Re: namespace support requires network modules to say GPL
Eric W. Biederman wrote: Patrick McHardy [EMAIL PROTECTED] writes: Ben Greear wrote: I have a binary module that uses dev_get_by_name...it's sort of a bridge-like thing and needs user-space to tell it which device to listen for packets on... This code doesn't need or care about name-spaces, so I don't see how it could really be infringing on the author's code (any worse than loading a binary driver into the kernel ever does). Regardless of infringement it is incompatible with a complete network namespace implementation. Further it sounds like the module you are describing defines a kernel ABI without being merged and hopes that ABI will still be supportable in the future. Honestly I think doing so is horrible code maintenance policy. I don't mind if the ABI changes, so long as I can still use something similar. The namespace logic is interesting to me in general, but at this point I can't think of a way that it actually helps this particular module. All I really need is a way to grab every frame from eth0 and then transmit it to eth1. I'm currently doing this by finding the netdevice and registering a raw-packet protocol (ie, like tcpdump would do). At least up to 2.6.23, this does not require any hacks to the kernel and uses only non GPL exported symbols. Based on my understanding of the namespace logic, if I never add any namespaces, the general network layout should look similar to how it does today, so I should have no logical problem with my module. Once things are largely complete it makes sense to argue with out of tree module authors that because they don't have network namespace support in their modules, their modules are broken. Does this imply that every module that accesses the network code *must* become GPL simply because it must interact with namespace logic that is exported as GPL only symbols? Thanks, Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com -- 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/
Re: namespace support requires network modules to say GPL
From: [EMAIL PROTECTED] (Eric W. Biederman) Date: Mon, 03 Dec 2007 11:03:38 -0700 Based on my experience with in-tree code and the few glimpses I have gotten of out of tree code the reason the out of tree code broke is because it is doing very questionable things. Calling dev_get_by_foo() was never ever a very questionable thing. Stop saying bullshit, because that's all that is coming out of your mouth in this thread. The fact is, these modules called perfectly fine interfaces and by adding namespaces YOU BROKE THEM. That by itself is OK, they can make the code changes to adapt and use the init namespace. Enforcing new licensing restrictions on them for existing interfaces just because you add a new freaking argument that is practically speaking a constant and always the same right now, on the other hand, IS NOT FINE and you must fix this now. I don't care how you do it. If you don't want them to get at the init namespace symbol, fine, revert all the dev_get_by_*() interfaces to not take the namespace symbol and make them internally use the init namespace albeit invisibly to the caller. Then you make all the existing call sites invoke new dev_get_by_*_ns() interfaces that take an explicit argument. But only do this where it is truly necessary, everything uses the init namespace practically speaking and it's clearer if you conver to the *_ns() variant when the code itself is converted. -- 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/
Re: namespace support requires network modules to say GPL
Ben Greear wrote: Eric W. Biederman wrote: Patrick McHardy [EMAIL PROTECTED] writes: Ben Greear wrote: I have a binary module that uses dev_get_by_name...it's sort of a bridge-like thing and needs user-space to tell it which device to listen for packets on... This code doesn't need or care about name-spaces, so I don't see how it could really be infringing on the author's code (any worse than loading a binary driver into the kernel ever does). Regardless of infringement it is incompatible with a complete network namespace implementation. Further it sounds like the module you are describing defines a kernel ABI without being merged and hopes that ABI will still be supportable in the future. Honestly I think doing so is horrible code maintenance policy. I don't mind if the ABI changes, so long as I can still use something similar. The namespace logic is interesting to me in general, but at this point I can't think of a way that it actually helps this particular module. All I really need is a way to grab every frame from eth0 and then transmit it to eth1. I'm currently doing this by finding the netdevice and registering a raw-packet protocol (ie, like tcpdump would do). At least up to 2.6.23, this does not require any hacks to the kernel and uses only non GPL exported symbols. Based on my understanding of the namespace logic, if I never add any namespaces, the general network layout should look similar to how it does today, so I should have no logical problem with my module. Once things are largely complete it makes sense to argue with out of tree module authors that because they don't have network namespace support in their modules, their modules are broken. Does this imply that every module that accesses the network code *must* become GPL simply because it must interact with namespace logic that is exported as GPL only symbols? That's right, with init_net's EXPORT_SYMBOL_GPL and dev_get_xx, we enforce people to be GPL whatever they didn't asked to have the namespaces in their code. Eric, why can we simply change EXPORT_SYMBOL_GPL to EXPORT_SYMBOL for init_net ? -- 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/
Re: namespace support requires network modules to say "GPL"
On Sun, Dec 02, 2007 at 10:59:46PM +0100, Patrick McHardy wrote: > Adrian Bunk wrote: >> On Sun, Dec 02, 2007 at 09:03:56PM +0100, Patrick McHardy wrote: >... >> your statement has an interesting implication: >> >> Stuff like e.g. the EXPORT_SYMBOL(sk_alloc) predates the EXPORT_SYMBOL_GPL >> stuff. >> >> Who is considered the author of this code? >> >> And when should he state whether he prefers to use EXPORT_SYMBOL_GPL but >> wasn't able to use it at that when he wrote it since his code predates it >> and is glad to be able to decide this now? > > He can state it when he feels like it, I don't see the point. > Authors generally get to decide whether they use EXPORT_SYMBOL > or EXPORT_SYMBOL_GPL unless in cases where its really clear-cut > that EXPORT_SYMBOL is inapproriate. But thats a different matter. >... You miss my point. Stuff like sk_alloc was exported to modules before EXPORT_SYMBOL_GPL existed (it was even exported to modules before EXPORT_SYMBOL existed). We are talking about code and exports that are at about 12 years old, which is at about twice as old as EXPORT_SYMBOL_GPL. So what should happen in your opinion if e.g. Alan checks which of the network code he had written when it was exported a dozen years ago, stating that he never wanted it to be available to non-GPL modules? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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/
Re: namespace support requires network modules to say "GPL"
> You license yours under the GPL, so they should respect the GPL. > > It sounds like we're back to where we were years ago. Didn't we already > agree that EXPORT_SYMBOL_GPL was *NOT* a GPL-enforcement mechanism and had > nothing to do with respecting the GPL? After all, if it s a GPL-enforcement No we seem to be back recycling the fact that certain people were making statements that might be construed, unanswered, as giving permission to violate the GPL. I'm merely reminding people that I've not waived my GPL rights, I've not said modules are somehow magically OK, and I don't agree with Linus. The GPL very clearly says that you can make your own unredistributed modifications and keep them that way. Alan -- 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/
RE: namespace support requires network modules to say "GPL"
> > Then init_net needs to be not GPL limited. Sorry, we need to allow > > non GPL network drivers. There is a fine line between keeping the > Why - they aren't exactly likely to be permissible by law Really? What law and/or what clause in the GPL says that derivative works have to be licensed under the GPL? Or does the kernel have some new technique to determine whether or not code has been distributed? As I read the GPL, it only requires you to release something under the GPL if you distribute it. The kernel has no idea whether or not code has been distributed. So if it's enforcing the GPL, it cannot prohibit anything non-distributed code can lawfully do. (Ergo, it's *NOT* *ENFORCING* the GPL.) > > binary seething masses from accessing random kernel functions, > and allowing > > reasonable (but still non GPL) things like ndiswrapper to use network > > device interface. > > Its up to the ndiswrapper authors how the licence their code, but they > should respect how we licence ours. You license yours under the GPL, so they should respect the GPL. It sounds like we're back to where we were years ago. Didn't we already agree that EXPORT_SYMBOL_GPL was *NOT* a GPL-enforcement mechanism and had nothing to do with respecting the GPL? After all, if it s a GPL-enforcement mechanism, why is it not a "further restriction" which is prohibited by the GPL? (The GPL contains no restrictions on what code can use what symbols if that code is not distributed, but EXPORT_SYMBOL_GPL does.) Are you now claiming that EXPORT_SYMBOL_GPL is intended to enforce the GPL? DS -- 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/
Re: namespace support requires network modules to say "GPL"
Adrian Bunk wrote: On Sun, Dec 02, 2007 at 09:03:56PM +0100, Patrick McHardy wrote: For all I care binary modules can break, but frankly I don't see how encapsulating a couple of structures and pointers in a new structure and adding a new argument to existing functions shifts the decision about how a function should be usable to the namespace guys. IMO all functions should continue to be usable as before, as decided by whoever actually wrote them. ... Even ignoring the fact that it's unclear whether distributing modules with not GPLv2 compatible licences is legal at all or might bring you in jail, Agreed, lets ignore that :) your statement has an interesting implication: Stuff like e.g. the EXPORT_SYMBOL(sk_alloc) predates the EXPORT_SYMBOL_GPL stuff. Who is considered the author of this code? And when should he state whether he prefers to use EXPORT_SYMBOL_GPL but wasn't able to use it at that when he wrote it since his code predates it and is glad to be able to decide this now? He can state it when he feels like it, I don't see the point. Authors generally get to decide whether they use EXPORT_SYMBOL or EXPORT_SYMBOL_GPL unless in cases where its really clear-cut that EXPORT_SYMBOL is inapproriate. But thats a different matter. If a symbol was OK to be used previously and something using it would not automatically be considered a derived work, how does passing _net to the function just to make the compiler happy, avoid BUG_ONs and generally keep things working as before make it more of a derived work? -- 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/
Re: namespace support requires network modules to say "GPL"
On Sun, Dec 02, 2007 at 09:03:56PM +0100, Patrick McHardy wrote: > Ben Greear wrote: >> Stephen Hemminger wrote: Naw, enterprise (or any other) distro vendors shouldn't have any issues here, since they can just patch their kernels around any issues. But it looks like Eric has this one thought out well enough. >>> >>> So you are saying all this is not a problem, fine. >>> Any affected parties can certainly lobby for themselves. But I suspect >>> they all think the kernel community is a bunch of ... and will just >>> ignore >>> the problem. > > >> I have a binary module that uses dev_get_by_name...it's sort of a >> bridge-like thing and >> needs user-space to tell it which device to listen for packets on... >> >> This code doesn't need or care about name-spaces, so I don't see how it >> could really >> be infringing on the author's code (any worse than loading a binary driver >> into the kernel >> ever does). >> >> I would certainly prefer to not have to patch around any problems with >> calling dev_get_by_name >> from a non-gpl module, but if required, I can probably figure something >> out... > > > For all I care binary modules can break, but frankly I don't see > how encapsulating a couple of structures and pointers in a new > structure and adding a new argument to existing functions shifts > the decision about how a function should be usable to the namespace > guys. IMO all functions should continue to be usable as before, > as decided by whoever actually wrote them. >... Even ignoring the fact that it's unclear whether distributing modules with not GPLv2 compatible licences is legal at all or might bring you in jail, your statement has an interesting implication: Stuff like e.g. the EXPORT_SYMBOL(sk_alloc) predates the EXPORT_SYMBOL_GPL stuff. Who is considered the author of this code? And when should he state whether he prefers to use EXPORT_SYMBOL_GPL but wasn't able to use it at that when he wrote it since his code predates it and is glad to be able to decide this now? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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/
Re: namespace support requires network modules to say "GPL"
Ben Greear wrote: Stephen Hemminger wrote: Naw, enterprise (or any other) distro vendors shouldn't have any issues here, since they can just patch their kernels around any issues. But it looks like Eric has this one thought out well enough. So you are saying all this is not a problem, fine. Any affected parties can certainly lobby for themselves. But I suspect they all think the kernel community is a bunch of ... and will just ignore the problem. > I have a binary module that uses dev_get_by_name...it's sort of a bridge-like thing and needs user-space to tell it which device to listen for packets on... This code doesn't need or care about name-spaces, so I don't see how it could really be infringing on the author's code (any worse than loading a binary driver into the kernel ever does). I would certainly prefer to not have to patch around any problems with calling dev_get_by_name from a non-gpl module, but if required, I can probably figure something out... For all I care binary modules can break, but frankly I don't see how encapsulating a couple of structures and pointers in a new structure and adding a new argument to existing functions shifts the decision about how a function should be usable to the namespace guys. IMO all functions should continue to be usable as before, as decided by whoever actually wrote them. The only exception might be stuff where an existing EXPORT_SYMBOL is clearly wrong, but that would be a seperate discussion. -- 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/
Re: namespace support requires network modules to say "GPL"
On Sun, 02 Dec 2007 13:51:04 GMT, Alan Cox said: > On Sat, 1 Dec 2007 16:30:35 -0800 > > I spoke too soon earlier, ndiswrapper builds and loads against current > > 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again > > I don't > > give a damn, but the enterprise distro vendors certainly care. > > Enterprise distro vendors ship kernels from the 2.6.19 era, so I don't > see why they care. They don't care *now*. They will care when they try to rev forward from .19. Not that they'll care a *lot* - it took *me* all of about an hour to get VMware Server 1.0.4 working under -rc3-mm2. Probably will take an enterprise distro 4-5 hours, 30 mins for the port and 4 1/2 hours for the paperwork. :) pgpa7N0zSI8ny.pgp Description: PGP signature
Re: namespace support requires network modules to say "GPL"
Stephen Hemminger wrote: Naw, enterprise (or any other) distro vendors shouldn't have any issues here, since they can just patch their kernels around any issues. But it looks like Eric has this one thought out well enough. So you are saying all this is not a problem, fine. Any affected parties can certainly lobby for themselves. But I suspect they all think the kernel community is a bunch of ... and will just ignore the problem. I have a binary module that uses dev_get_by_name...it's sort of a bridge-like thing and needs user-space to tell it which device to listen for packets on... This code doesn't need or care about name-spaces, so I don't see how it could really be infringing on the author's code (any worse than loading a binary driver into the kernel ever does). I would certainly prefer to not have to patch around any problems with calling dev_get_by_name from a non-gpl module, but if required, I can probably figure something out... Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com -- 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/
Re: namespace support requires network modules to say "GPL"
On Sat, 1 Dec 2007 16:30:35 -0800 Stephen Hemminger <[EMAIL PROTECTED]> wrote: > On Sat, 1 Dec 2007 11:17:36 -0800 > Stephen Hemminger <[EMAIL PROTECTED]> wrote: > > > Then init_net needs to be not GPL limited. Sorry, we need to allow > > non GPL network drivers. There is a fine line between keeping the > > binary seething masses from accessing random kernel functions, and allowing > > reasonable (but still non GPL) things like ndiswrapper to use network > > device interface. > > > I spoke too soon earlier, ndiswrapper builds and loads against current > 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again I > don't > give a damn, but the enterprise distro vendors certainly care. Enterprise distro vendors ship kernels from the 2.6.19 era, so I don't see why they care. Alan -- 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/
Re: namespace support requires network modules to say GPL
On Sat, 1 Dec 2007 16:30:35 -0800 Stephen Hemminger [EMAIL PROTECTED] wrote: On Sat, 1 Dec 2007 11:17:36 -0800 Stephen Hemminger [EMAIL PROTECTED] wrote: Then init_net needs to be not GPL limited. Sorry, we need to allow non GPL network drivers. There is a fine line between keeping the binary seething masses from accessing random kernel functions, and allowing reasonable (but still non GPL) things like ndiswrapper to use network device interface. I spoke too soon earlier, ndiswrapper builds and loads against current 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again I don't give a damn, but the enterprise distro vendors certainly care. Enterprise distro vendors ship kernels from the 2.6.19 era, so I don't see why they care. Alan -- 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/
Re: namespace support requires network modules to say GPL
Stephen Hemminger wrote: Naw, enterprise (or any other) distro vendors shouldn't have any issues here, since they can just patch their kernels around any issues. But it looks like Eric has this one thought out well enough. So you are saying all this is not a problem, fine. Any affected parties can certainly lobby for themselves. But I suspect they all think the kernel community is a bunch of ... and will just ignore the problem. I have a binary module that uses dev_get_by_name...it's sort of a bridge-like thing and needs user-space to tell it which device to listen for packets on... This code doesn't need or care about name-spaces, so I don't see how it could really be infringing on the author's code (any worse than loading a binary driver into the kernel ever does). I would certainly prefer to not have to patch around any problems with calling dev_get_by_name from a non-gpl module, but if required, I can probably figure something out... Thanks, Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com -- 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/
Re: namespace support requires network modules to say GPL
On Sun, 02 Dec 2007 13:51:04 GMT, Alan Cox said: On Sat, 1 Dec 2007 16:30:35 -0800 I spoke too soon earlier, ndiswrapper builds and loads against current 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again I don't give a damn, but the enterprise distro vendors certainly care. Enterprise distro vendors ship kernels from the 2.6.19 era, so I don't see why they care. They don't care *now*. They will care when they try to rev forward from .19. Not that they'll care a *lot* - it took *me* all of about an hour to get VMware Server 1.0.4 working under -rc3-mm2. Probably will take an enterprise distro 4-5 hours, 30 mins for the port and 4 1/2 hours for the paperwork. :) pgpa7N0zSI8ny.pgp Description: PGP signature
Re: namespace support requires network modules to say GPL
Ben Greear wrote: Stephen Hemminger wrote: Naw, enterprise (or any other) distro vendors shouldn't have any issues here, since they can just patch their kernels around any issues. But it looks like Eric has this one thought out well enough. So you are saying all this is not a problem, fine. Any affected parties can certainly lobby for themselves. But I suspect they all think the kernel community is a bunch of ... and will just ignore the problem. I have a binary module that uses dev_get_by_name...it's sort of a bridge-like thing and needs user-space to tell it which device to listen for packets on... This code doesn't need or care about name-spaces, so I don't see how it could really be infringing on the author's code (any worse than loading a binary driver into the kernel ever does). I would certainly prefer to not have to patch around any problems with calling dev_get_by_name from a non-gpl module, but if required, I can probably figure something out... For all I care binary modules can break, but frankly I don't see how encapsulating a couple of structures and pointers in a new structure and adding a new argument to existing functions shifts the decision about how a function should be usable to the namespace guys. IMO all functions should continue to be usable as before, as decided by whoever actually wrote them. The only exception might be stuff where an existing EXPORT_SYMBOL is clearly wrong, but that would be a seperate discussion. -- 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/
Re: namespace support requires network modules to say GPL
On Sun, Dec 02, 2007 at 09:03:56PM +0100, Patrick McHardy wrote: Ben Greear wrote: Stephen Hemminger wrote: Naw, enterprise (or any other) distro vendors shouldn't have any issues here, since they can just patch their kernels around any issues. But it looks like Eric has this one thought out well enough. So you are saying all this is not a problem, fine. Any affected parties can certainly lobby for themselves. But I suspect they all think the kernel community is a bunch of ... and will just ignore the problem. I have a binary module that uses dev_get_by_name...it's sort of a bridge-like thing and needs user-space to tell it which device to listen for packets on... This code doesn't need or care about name-spaces, so I don't see how it could really be infringing on the author's code (any worse than loading a binary driver into the kernel ever does). I would certainly prefer to not have to patch around any problems with calling dev_get_by_name from a non-gpl module, but if required, I can probably figure something out... For all I care binary modules can break, but frankly I don't see how encapsulating a couple of structures and pointers in a new structure and adding a new argument to existing functions shifts the decision about how a function should be usable to the namespace guys. IMO all functions should continue to be usable as before, as decided by whoever actually wrote them. ... Even ignoring the fact that it's unclear whether distributing modules with not GPLv2 compatible licences is legal at all or might bring you in jail, your statement has an interesting implication: Stuff like e.g. the EXPORT_SYMBOL(sk_alloc) predates the EXPORT_SYMBOL_GPL stuff. Who is considered the author of this code? And when should he state whether he prefers to use EXPORT_SYMBOL_GPL but wasn't able to use it at that when he wrote it since his code predates it and is glad to be able to decide this now? cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- 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/
Re: namespace support requires network modules to say GPL
Adrian Bunk wrote: On Sun, Dec 02, 2007 at 09:03:56PM +0100, Patrick McHardy wrote: For all I care binary modules can break, but frankly I don't see how encapsulating a couple of structures and pointers in a new structure and adding a new argument to existing functions shifts the decision about how a function should be usable to the namespace guys. IMO all functions should continue to be usable as before, as decided by whoever actually wrote them. ... Even ignoring the fact that it's unclear whether distributing modules with not GPLv2 compatible licences is legal at all or might bring you in jail, Agreed, lets ignore that :) your statement has an interesting implication: Stuff like e.g. the EXPORT_SYMBOL(sk_alloc) predates the EXPORT_SYMBOL_GPL stuff. Who is considered the author of this code? And when should he state whether he prefers to use EXPORT_SYMBOL_GPL but wasn't able to use it at that when he wrote it since his code predates it and is glad to be able to decide this now? He can state it when he feels like it, I don't see the point. Authors generally get to decide whether they use EXPORT_SYMBOL or EXPORT_SYMBOL_GPL unless in cases where its really clear-cut that EXPORT_SYMBOL is inapproriate. But thats a different matter. If a symbol was OK to be used previously and something using it would not automatically be considered a derived work, how does passing init_net to the function just to make the compiler happy, avoid BUG_ONs and generally keep things working as before make it more of a derived work? -- 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/
RE: namespace support requires network modules to say GPL
Then init_net needs to be not GPL limited. Sorry, we need to allow non GPL network drivers. There is a fine line between keeping the Why - they aren't exactly likely to be permissible by law Really? What law and/or what clause in the GPL says that derivative works have to be licensed under the GPL? Or does the kernel have some new technique to determine whether or not code has been distributed? As I read the GPL, it only requires you to release something under the GPL if you distribute it. The kernel has no idea whether or not code has been distributed. So if it's enforcing the GPL, it cannot prohibit anything non-distributed code can lawfully do. (Ergo, it's *NOT* *ENFORCING* the GPL.) binary seething masses from accessing random kernel functions, and allowing reasonable (but still non GPL) things like ndiswrapper to use network device interface. Its up to the ndiswrapper authors how the licence their code, but they should respect how we licence ours. You license yours under the GPL, so they should respect the GPL. It sounds like we're back to where we were years ago. Didn't we already agree that EXPORT_SYMBOL_GPL was *NOT* a GPL-enforcement mechanism and had nothing to do with respecting the GPL? After all, if it s a GPL-enforcement mechanism, why is it not a further restriction which is prohibited by the GPL? (The GPL contains no restrictions on what code can use what symbols if that code is not distributed, but EXPORT_SYMBOL_GPL does.) Are you now claiming that EXPORT_SYMBOL_GPL is intended to enforce the GPL? DS -- 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/
Re: namespace support requires network modules to say GPL
You license yours under the GPL, so they should respect the GPL. It sounds like we're back to where we were years ago. Didn't we already agree that EXPORT_SYMBOL_GPL was *NOT* a GPL-enforcement mechanism and had nothing to do with respecting the GPL? After all, if it s a GPL-enforcement No we seem to be back recycling the fact that certain people were making statements that might be construed, unanswered, as giving permission to violate the GPL. I'm merely reminding people that I've not waived my GPL rights, I've not said modules are somehow magically OK, and I don't agree with Linus. The GPL very clearly says that you can make your own unredistributed modifications and keep them that way. Alan -- 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/
Re: namespace support requires network modules to say GPL
On Sun, Dec 02, 2007 at 10:59:46PM +0100, Patrick McHardy wrote: Adrian Bunk wrote: On Sun, Dec 02, 2007 at 09:03:56PM +0100, Patrick McHardy wrote: ... your statement has an interesting implication: Stuff like e.g. the EXPORT_SYMBOL(sk_alloc) predates the EXPORT_SYMBOL_GPL stuff. Who is considered the author of this code? And when should he state whether he prefers to use EXPORT_SYMBOL_GPL but wasn't able to use it at that when he wrote it since his code predates it and is glad to be able to decide this now? He can state it when he feels like it, I don't see the point. Authors generally get to decide whether they use EXPORT_SYMBOL or EXPORT_SYMBOL_GPL unless in cases where its really clear-cut that EXPORT_SYMBOL is inapproriate. But thats a different matter. ... You miss my point. Stuff like sk_alloc was exported to modules before EXPORT_SYMBOL_GPL existed (it was even exported to modules before EXPORT_SYMBOL existed). We are talking about code and exports that are at about 12 years old, which is at about twice as old as EXPORT_SYMBOL_GPL. So what should happen in your opinion if e.g. Alan checks which of the network code he had written when it was exported a dozen years ago, stating that he never wanted it to be available to non-GPL modules? cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- 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/
Re: namespace support requires network modules to say "GPL"
On Sat, 01 Dec 2007 22:34:09 -0500 Mark Lord <[EMAIL PROTECTED]> wrote: > Stephen Hemminger wrote: > > On Sat, 1 Dec 2007 11:17:36 -0800 > > Stephen Hemminger <[EMAIL PROTECTED]> wrote: > > > >> Then init_net needs to be not GPL limited. Sorry, we need to allow > >> non GPL network drivers. There is a fine line between keeping the > >> binary seething masses from accessing random kernel functions, and allowing > >> reasonable (but still non GPL) things like ndiswrapper to use network > >> device interface. > >> > > I spoke too soon earlier, ndiswrapper builds and loads against current > > 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again > > I don't > > give a damn, but the enterprise distro vendors certainly care. > ... > > Naw, enterprise (or any other) distro vendors shouldn't have any issues here, > since they can just patch their kernels around any issues. > > But it looks like Eric has this one thought out well enough. So you are saying all this is not a problem, fine. Any affected parties can certainly lobby for themselves. But I suspect they all think the kernel community is a bunch of ... and will just ignore the problem. -- Stephen Hemminger <[EMAIL PROTECTED]> -- 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/
Re: namespace support requires network modules to say "GPL"
Stephen Hemminger wrote: On Sat, 1 Dec 2007 11:17:36 -0800 Stephen Hemminger <[EMAIL PROTECTED]> wrote: Then init_net needs to be not GPL limited. Sorry, we need to allow non GPL network drivers. There is a fine line between keeping the binary seething masses from accessing random kernel functions, and allowing reasonable (but still non GPL) things like ndiswrapper to use network device interface. I spoke too soon earlier, ndiswrapper builds and loads against current 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again I don't give a damn, but the enterprise distro vendors certainly care. ... Naw, enterprise (or any other) distro vendors shouldn't have any issues here, since they can just patch their kernels around any issues. But it looks like Eric has this one thought out well enough. Cheers -- 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/
Re: namespace support requires network modules to say "GPL"
Stephen Hemminger <[EMAIL PROTECTED]> writes: > On Sat, 1 Dec 2007 11:17:36 -0800 > Stephen Hemminger <[EMAIL PROTECTED]> wrote: > >> Then init_net needs to be not GPL limited. Sorry, we need to allow >> non GPL network drivers. There is a fine line between keeping the >> binary seething masses from accessing random kernel functions, and allowing >> reasonable (but still non GPL) things like ndiswrapper to use network >> device interface. >> > I spoke too soon earlier, ndiswrapper builds and loads against current > 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again I > don't > give a damn, but the enterprise distro vendors certainly care. It looks like someone found a work around for vmware. As for proprietary VPN software, the one case that came of David Miller said we had sufficient alternatives in the kernel that he didn't care. We have to make a lot of changes to get the network namespaces complete. I don't have pity on any external code that breaks because they won't let me at their code. If it turns out the code that was broken was an unacknowledged derivative work and it can't be fixed I have even less pity on them. 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/
Re: namespace support requires network modules to say "GPL"
Jiri Slaby <[EMAIL PROTECTED]> writes: > On 12/02/2007 12:13 AM, Eric W. Biederman wrote: >> Mark Lord <[EMAIL PROTECTED]> writes: >>> 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_. Only protocols call sk_alloc. >> >>> and many want to do register_netdev(). >> >> I haven't even touched register_netdev. >> >>> So what should they be using there ? >> >> What are you having problems with? >> >> It is hard to answer specific questions without a context. > > VMware vmnet. With a quick glance in that direction it appears to the result of a design bug in vmnet that they call sk_alloc at all, and someone seems to have found a work around in vmnet for this situation. My gut feel is that vmware should just use tun or tap (whichever is the appropriate one), and be done with it. 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/
Re: namespace support requires network modules to say "GPL"
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_ 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_. 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(>queue_lock); >> spin_lock_init(>_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 "_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/
Re: namespace support requires network modules to say "GPL"
On Sat, 1 Dec 2007 11:17:36 -0800 Stephen Hemminger <[EMAIL PROTECTED]> wrote: > Then init_net needs to be not GPL limited. Sorry, we need to allow > non GPL network drivers. There is a fine line between keeping the > binary seething masses from accessing random kernel functions, and allowing > reasonable (but still non GPL) things like ndiswrapper to use network > device interface. > I spoke too soon earlier, ndiswrapper builds and loads against current 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again I don't give a damn, but the enterprise distro vendors certainly care. -- Stephen Hemminger <[EMAIL PROTECTED]> -- Stephen Hemminger <[EMAIL PROTECTED]> -- 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/
Re: namespace support requires network modules to say "GPL"
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_ 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_. 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: 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(>queue_lock); spin_lock_init(>_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 "_net". So what should they be using there ? What are you having problems with? .. Avoiding the question again there, too. 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. Cheers -- 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/
Re: namespace support requires network modules to say "GPL"
On 12/02/2007 12:13 AM, Eric W. Biederman wrote: > Mark Lord <[EMAIL PROTECTED]> writes: >> 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_. Only protocols call sk_alloc. > >> and many want to do register_netdev(). > > I haven't even touched register_netdev. > >> So what should they be using there ? > > What are you having problems with? > > It is hard to answer specific questions without a context. VMware vmnet. -- 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/
Re: namespace support requires network modules to say "GPL"
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_ 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_. Only protocols call sk_alloc. > and many want to do register_netdev(). I haven't even touched register_netdev. > So what should they be using there ? What are you having problems with? It is hard to answer specific questions without a context. 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/
Re: namespace support requires network modules to say "GPL"
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_ 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(), and many want to do register_netdev(). So what should they be using there ? And please STOP trimming the CC list. -- 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/
Re: namespace support requires network modules to say "GPL"
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_ 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(), and many want to do register_netdev(). So what should they be using there ? -- 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/
Re: namespace support requires network modules to say "GPL"
Mark Lord <[EMAIL PROTECTED]> writes: >>> Can we get this resolved before 2.6.24 is released? Going back and forth >>> on API's is just needless frottage. >> >> Sure. We keep the updated dev_get_by_ that takes a network >> namespace parameter. > .. > > And what should code be passing in when "# CONFIG_NET_NS is not set" ? Mostly CONFIG_NET_NS is a define to keep us from exposing the feature to user space not to remove the code impact. People could not stand the look of the code that would actually allow us to compile everything out. So all of the struct net * fields remain when !CONFIG_NET_NS. Including the global variable init_net. 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/
Re: namespace support requires network modules to say "GPL"
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_ 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... in fact no NIC driver in drivers/net does so! Sounds like whatever driver you're looking at has a nasty bug in that it's using non-driver APIs... -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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/
Re: namespace support requires network modules to say "GPL"
Eric W. Biederman wrote: Stephen Hemminger <[EMAIL PROTECTED]> writes: Actually, the whole mess would go away if the api for dev_get_by_ hadn't been changed in the namespace transition. IMHO the interface to dev_get_by_name() should not have added a namespace parameter, of the callers in the tree, only two use a different namespace. So it would have been better to to introduce dev_get_by_name_ns() with the extra parameter. As a general rule if you are calling dev_get_by_name and taking an _net parameter that means you code has not yet been converted to actually support network namespaces. Not everything can be safely changed at once so we take it by steps. When the code fully supports network namespaces practically nothing will take an _net parameter. The network namespace parameter will come in some form from userspace. Either from current or from the network socket. Except for boot time initialization I don't know of any cases using dev_get_by_ that won't need to be modified before the network namespace work is complete. I believe I mentioned that this getting the fully network namespace support was going to take a while and a bunch of patches at the outset. Can we get this resolved before 2.6.24 is released? Going back and forth on API's is just needless frottage. Sure. We keep the updated dev_get_by_ that takes a network namespace parameter. .. And what should code be passing in when "# CONFIG_NET_NS is not set" ? -- 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/
Re: namespace support requires network modules to say "GPL"
Stephen Hemminger <[EMAIL PROTECTED]> writes: > Actually, the whole mess would go away if the api for dev_get_by_ hadn't > been changed in the namespace transition. IMHO the interface to > dev_get_by_name() > should not have added a namespace parameter, of the callers in the tree, only > two use a different namespace. So it would have been better to to introduce > dev_get_by_name_ns() with the extra parameter. As a general rule if you are calling dev_get_by_name and taking an _net parameter that means you code has not yet been converted to actually support network namespaces. Not everything can be safely changed at once so we take it by steps. When the code fully supports network namespaces practically nothing will take an _net parameter. The network namespace parameter will come in some form from userspace. Either from current or from the network socket. Except for boot time initialization I don't know of any cases using dev_get_by_ that won't need to be modified before the network namespace work is complete. I believe I mentioned that this getting the fully network namespace support was going to take a while and a bunch of patches at the outset. > Can we get this resolved before 2.6.24 is released? Going back and forth > on API's is just needless frottage. Sure. We keep the updated dev_get_by_ that takes a network namespace parameter. Or is their some legitimate usage of it by out of tree code that I'm not aware of? 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/
Re: namespace support requires network modules to say "GPL"
Stephen Hemminger <[EMAIL PROTECTED]> writes:
> On Sat, 01 Dec 2007 08:10:17 -0500
> Mark Lord <[EMAIL PROTECTED]> wrote:
>
>> > Now that we have network namespace support merged it is time to
>> > revisit the sysfs support so we can remove the dependency on !SYSFS.
>> ...
>>
>> Now that the namespace updates are part of 2.6.24,
>> there is a major inconsistency in network EXPORT_SYMBOLs.
>>
>> It used to be that an external network module could get away without
>> having to add a MODULE_LICENSE("GPL*") line to the source.
>>
>> In support of that, common networking functions (still) use EXPORT_SYMBOL()
>> rather than the more restrictive EXPORT_SYMBOL_GPL().
>>
>> Eg. register_netdev(), sk_alloc(), __dev_get_by_name().
>>
>> But now, none of those three are actually usable by default,
>> because they all require "init_net", which is EXPORT_SYMBOL_GPL().
Which alternative kernel does the above comment apply to?
> Then init_net needs to be not GPL limited. Sorry, we need to allow
> non GPL network drivers.
For the record network drivers should not be affected. As a practical
measure that just gets unmaintainable and it is unnecessary.
There are specific exceptions where network drivers mess with the userspace
interfaces where I do have some impact. However if you are messing
with our userspace interface especially with network namespaces in place
I don't see how it is possible for you to be anything other then a derivative
work, and something we need in tree to keep maintenance a manageable thing.
It should just be the core of the network stack that struct net has some
effect on.
> There is a fine line between keeping the
> binary seething masses from accessing random kernel functions, and allowing
> reasonable (but still non GPL) things like ndiswrapper to use network
> device interface.
Does ndiswrapper break? If so what dubious and unsupportable thing is
it doing?
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/
Re: namespace support requires network modules to say "GPL"
> Then change the license, explicitly and get it approved, forcing license > changes by technically subversive means is bad policy. It is like Euro > bureaucrats I don't need to - the licence has been the same since about 0.12 Alan -- 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/
Re: namespace support requires network modules to say "GPL"
On Sat, 1 Dec 2007 19:23:41 + Alan Cox <[EMAIL PROTECTED]> wrote: > > Then init_net needs to be not GPL limited. Sorry, we need to allow > > non GPL network drivers. There is a fine line between keeping the > > Why - they aren't exactly likely to be permissible by law Matter of debate in which there are several opinions. I don't like binary modules either, but don't feel qualified to render a legal opinion. > > > binary seething masses from accessing random kernel functions, and allowing > > reasonable (but still non GPL) things like ndiswrapper to use network > > device interface. > > Its up to the ndiswrapper authors how the licence their code, but they > should respect how we licence ours. Then change the license, explicitly and get it approved, forcing license changes by technically subversive means is bad policy. It is like Euro bureaucrats sneaking in software patents in regulations. If you want to have the debate and can get it resolved, then I support you. Actually, the whole mess would go away if the api for dev_get_by_ hadn't been changed in the namespace transition. IMHO the interface to dev_get_by_name() should not have added a namespace parameter, of the callers in the tree, only two use a different namespace. So it would have been better to to introduce dev_get_by_name_ns() with the extra parameter. Can we get this resolved before 2.6.24 is released? Going back and forth on API's is just needless frottage. -- Stephen Hemminger <[EMAIL PROTECTED]> -- 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/
Re: namespace support requires network modules to say "GPL"
> Then init_net needs to be not GPL limited. Sorry, we need to allow > non GPL network drivers. There is a fine line between keeping the Why - they aren't exactly likely to be permissible by law > binary seething masses from accessing random kernel functions, and allowing > reasonable (but still non GPL) things like ndiswrapper to use network > device interface. Its up to the ndiswrapper authors how the licence their code, but they should respect how we licence ours. -- 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/
Re: namespace support requires network modules to say "GPL"
On Sat, 01 Dec 2007 08:10:17 -0500
Mark Lord <[EMAIL PROTECTED]> wrote:
> > Now that we have network namespace support merged it is time to
> > revisit the sysfs support so we can remove the dependency on !SYSFS.
> ...
>
> Now that the namespace updates are part of 2.6.24,
> there is a major inconsistency in network EXPORT_SYMBOLs.
>
> It used to be that an external network module could get away without
> having to add a MODULE_LICENSE("GPL*") line to the source.
>
> In support of that, common networking functions (still) use EXPORT_SYMBOL()
> rather than the more restrictive EXPORT_SYMBOL_GPL().
>
> Eg. register_netdev(), sk_alloc(), __dev_get_by_name().
>
> But now, none of those three are actually usable by default,
> because they all require "init_net", which is EXPORT_SYMBOL_GPL().
>
Then init_net needs to be not GPL limited. Sorry, we need to allow
non GPL network drivers. There is a fine line between keeping the
binary seething masses from accessing random kernel functions, and allowing
reasonable (but still non GPL) things like ndiswrapper to use network
device interface.
--
Stephen Hemminger <[EMAIL PROTECTED]>
--
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/
Re: namespace support requires network modules to say "GPL"
Mark Lord wrote:
Now that we have network namespace support merged it is time to
revisit the sysfs support so we can remove the dependency on !SYSFS.
...
Now that the namespace updates are part of 2.6.24,
there is a major inconsistency in network EXPORT_SYMBOLs.
It used to be that an external network module could get away without
having to add a MODULE_LICENSE("GPL*") line to the source.
In support of that, common networking functions (still) use EXPORT_SYMBOL()
rather than the more restrictive EXPORT_SYMBOL_GPL().
Eg. register_netdev(), sk_alloc(), __dev_get_by_name().
But now, none of those three are actually usable by default,
because they all require "init_net", which is EXPORT_SYMBOL_GPL().
So.. It appears that one of three things should really happen next:
1) Change the other exports to also be EXPORT_SYMBOL_GPL.
2) Have register_netdev, sk_alloc, and __dev_get_by_name default
to using init_net when NULL is specified in the namespace field.
or
3) Change init_net to be EXPORT_SYMBOL_GPL.
..
Obviously that should instead say:
3) Change init_net to be EXPORT_SYMBOL instead of EXPORT_SYMBOL_GPL.
--
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/
Re: namespace support requires network modules to say GPL
Mark Lord wrote: Now that we have network namespace support merged it is time to revisit the sysfs support so we can remove the dependency on !SYSFS. ... Now that the namespace updates are part of 2.6.24, there is a major inconsistency in network EXPORT_SYMBOLs. It used to be that an external network module could get away without having to add a MODULE_LICENSE(GPL*) line to the source. In support of that, common networking functions (still) use EXPORT_SYMBOL() rather than the more restrictive EXPORT_SYMBOL_GPL(). Eg. register_netdev(), sk_alloc(), __dev_get_by_name(). But now, none of those three are actually usable by default, because they all require init_net, which is EXPORT_SYMBOL_GPL(). So.. It appears that one of three things should really happen next: 1) Change the other exports to also be EXPORT_SYMBOL_GPL. 2) Have register_netdev, sk_alloc, and __dev_get_by_name default to using init_net when NULL is specified in the namespace field. or 3) Change init_net to be EXPORT_SYMBOL_GPL. .. Obviously that should instead say: 3) Change init_net to be EXPORT_SYMBOL instead of EXPORT_SYMBOL_GPL. -- 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/
Re: namespace support requires network modules to say GPL
On Sat, 01 Dec 2007 08:10:17 -0500 Mark Lord [EMAIL PROTECTED] wrote: Now that we have network namespace support merged it is time to revisit the sysfs support so we can remove the dependency on !SYSFS. ... Now that the namespace updates are part of 2.6.24, there is a major inconsistency in network EXPORT_SYMBOLs. It used to be that an external network module could get away without having to add a MODULE_LICENSE(GPL*) line to the source. In support of that, common networking functions (still) use EXPORT_SYMBOL() rather than the more restrictive EXPORT_SYMBOL_GPL(). Eg. register_netdev(), sk_alloc(), __dev_get_by_name(). But now, none of those three are actually usable by default, because they all require init_net, which is EXPORT_SYMBOL_GPL(). Then init_net needs to be not GPL limited. Sorry, we need to allow non GPL network drivers. There is a fine line between keeping the binary seething masses from accessing random kernel functions, and allowing reasonable (but still non GPL) things like ndiswrapper to use network device interface. -- Stephen Hemminger [EMAIL PROTECTED] -- 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/
Re: namespace support requires network modules to say GPL
Then init_net needs to be not GPL limited. Sorry, we need to allow non GPL network drivers. There is a fine line between keeping the Why - they aren't exactly likely to be permissible by law binary seething masses from accessing random kernel functions, and allowing reasonable (but still non GPL) things like ndiswrapper to use network device interface. Its up to the ndiswrapper authors how the licence their code, but they should respect how we licence ours. -- 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/
Re: namespace support requires network modules to say GPL
Then change the license, explicitly and get it approved, forcing license changes by technically subversive means is bad policy. It is like Euro bureaucrats I don't need to - the licence has been the same since about 0.12 Alan -- 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/
Re: namespace support requires network modules to say GPL
Stephen Hemminger [EMAIL PROTECTED] writes: On Sat, 01 Dec 2007 08:10:17 -0500 Mark Lord [EMAIL PROTECTED] wrote: Now that we have network namespace support merged it is time to revisit the sysfs support so we can remove the dependency on !SYSFS. ... Now that the namespace updates are part of 2.6.24, there is a major inconsistency in network EXPORT_SYMBOLs. It used to be that an external network module could get away without having to add a MODULE_LICENSE(GPL*) line to the source. In support of that, common networking functions (still) use EXPORT_SYMBOL() rather than the more restrictive EXPORT_SYMBOL_GPL(). Eg. register_netdev(), sk_alloc(), __dev_get_by_name(). But now, none of those three are actually usable by default, because they all require init_net, which is EXPORT_SYMBOL_GPL(). Which alternative kernel does the above comment apply to? Then init_net needs to be not GPL limited. Sorry, we need to allow non GPL network drivers. For the record network drivers should not be affected. As a practical measure that just gets unmaintainable and it is unnecessary. There are specific exceptions where network drivers mess with the userspace interfaces where I do have some impact. However if you are messing with our userspace interface especially with network namespaces in place I don't see how it is possible for you to be anything other then a derivative work, and something we need in tree to keep maintenance a manageable thing. It should just be the core of the network stack that struct net has some effect on. There is a fine line between keeping the binary seething masses from accessing random kernel functions, and allowing reasonable (but still non GPL) things like ndiswrapper to use network device interface. Does ndiswrapper break? If so what dubious and unsupportable thing is it doing? 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/
Re: namespace support requires network modules to say GPL
On Sat, 1 Dec 2007 19:23:41 + Alan Cox [EMAIL PROTECTED] wrote: Then init_net needs to be not GPL limited. Sorry, we need to allow non GPL network drivers. There is a fine line between keeping the Why - they aren't exactly likely to be permissible by law Matter of debate in which there are several opinions. I don't like binary modules either, but don't feel qualified to render a legal opinion. binary seething masses from accessing random kernel functions, and allowing reasonable (but still non GPL) things like ndiswrapper to use network device interface. Its up to the ndiswrapper authors how the licence their code, but they should respect how we licence ours. Then change the license, explicitly and get it approved, forcing license changes by technically subversive means is bad policy. It is like Euro bureaucrats sneaking in software patents in regulations. If you want to have the debate and can get it resolved, then I support you. Actually, the whole mess would go away if the api for dev_get_by_ hadn't been changed in the namespace transition. IMHO the interface to dev_get_by_name() should not have added a namespace parameter, of the callers in the tree, only two use a different namespace. So it would have been better to to introduce dev_get_by_name_ns() with the extra parameter. Can we get this resolved before 2.6.24 is released? Going back and forth on API's is just needless frottage. -- Stephen Hemminger [EMAIL PROTECTED] -- 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/
Re: namespace support requires network modules to say GPL
Stephen Hemminger [EMAIL PROTECTED] writes: Actually, the whole mess would go away if the api for dev_get_by_ hadn't been changed in the namespace transition. IMHO the interface to dev_get_by_name() should not have added a namespace parameter, of the callers in the tree, only two use a different namespace. So it would have been better to to introduce dev_get_by_name_ns() with the extra parameter. As a general rule if you are calling dev_get_by_name and taking an init_net parameter that means you code has not yet been converted to actually support network namespaces. Not everything can be safely changed at once so we take it by steps. When the code fully supports network namespaces practically nothing will take an init_net parameter. The network namespace parameter will come in some form from userspace. Either from current or from the network socket. Except for boot time initialization I don't know of any cases using dev_get_by_ that won't need to be modified before the network namespace work is complete. I believe I mentioned that this getting the fully network namespace support was going to take a while and a bunch of patches at the outset. Can we get this resolved before 2.6.24 is released? Going back and forth on API's is just needless frottage. Sure. We keep the updated dev_get_by_ that takes a network namespace parameter. Or is their some legitimate usage of it by out of tree code that I'm not aware of? 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/
Re: namespace support requires network modules to say GPL
Eric W. Biederman wrote: Stephen Hemminger [EMAIL PROTECTED] writes: Actually, the whole mess would go away if the api for dev_get_by_ hadn't been changed in the namespace transition. IMHO the interface to dev_get_by_name() should not have added a namespace parameter, of the callers in the tree, only two use a different namespace. So it would have been better to to introduce dev_get_by_name_ns() with the extra parameter. As a general rule if you are calling dev_get_by_name and taking an init_net parameter that means you code has not yet been converted to actually support network namespaces. Not everything can be safely changed at once so we take it by steps. When the code fully supports network namespaces practically nothing will take an init_net parameter. The network namespace parameter will come in some form from userspace. Either from current or from the network socket. Except for boot time initialization I don't know of any cases using dev_get_by_ that won't need to be modified before the network namespace work is complete. I believe I mentioned that this getting the fully network namespace support was going to take a while and a bunch of patches at the outset. Can we get this resolved before 2.6.24 is released? Going back and forth on API's is just needless frottage. Sure. We keep the updated dev_get_by_ that takes a network namespace parameter. .. And what should code be passing in when # CONFIG_NET_NS is not set ? -- 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/
Re: namespace support requires network modules to say GPL
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_ 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... in fact no NIC driver in drivers/net does so! Sounds like whatever driver you're looking at has a nasty bug in that it's using non-driver APIs... -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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/
Re: namespace support requires network modules to say GPL
Mark Lord [EMAIL PROTECTED] writes: Can we get this resolved before 2.6.24 is released? Going back and forth on API's is just needless frottage. Sure. We keep the updated dev_get_by_ that takes a network namespace parameter. .. And what should code be passing in when # CONFIG_NET_NS is not set ? Mostly CONFIG_NET_NS is a define to keep us from exposing the feature to user space not to remove the code impact. People could not stand the look of the code that would actually allow us to compile everything out. So all of the struct net * fields remain when !CONFIG_NET_NS. Including the global variable init_net. 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/
Re: namespace support requires network modules to say GPL
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_ 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(), and many want to do register_netdev(). So what should they be using there ? -- 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/
Re: namespace support requires network modules to say GPL
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_ 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(), and many want to do register_netdev(). So what should they be using there ? And please STOP trimming the CC list. -- 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/
Re: namespace support requires network modules to say GPL
On 12/02/2007 12:13 AM, Eric W. Biederman wrote: Mark Lord [EMAIL PROTECTED] writes: 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_. Only protocols call sk_alloc. and many want to do register_netdev(). I haven't even touched register_netdev. So what should they be using there ? What are you having problems with? It is hard to answer specific questions without a context. VMware vmnet. -- 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/
Re: namespace support requires network modules to say GPL
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_ 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_. Only protocols call sk_alloc. and many want to do register_netdev(). I haven't even touched register_netdev. So what should they be using there ? What are you having problems with? It is hard to answer specific questions without a context. 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/
Re: namespace support requires network modules to say GPL
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_ 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_. 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: 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. So what should they be using there ? What are you having problems with? .. Avoiding the question again there, too. 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. Cheers -- 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/
Re: namespace support requires network modules to say GPL
On Sat, 1 Dec 2007 11:17:36 -0800 Stephen Hemminger [EMAIL PROTECTED] wrote: Then init_net needs to be not GPL limited. Sorry, we need to allow non GPL network drivers. There is a fine line between keeping the binary seething masses from accessing random kernel functions, and allowing reasonable (but still non GPL) things like ndiswrapper to use network device interface. I spoke too soon earlier, ndiswrapper builds and loads against current 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again I don't give a damn, but the enterprise distro vendors certainly care. -- Stephen Hemminger [EMAIL PROTECTED] -- Stephen Hemminger [EMAIL PROTECTED] -- 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/
Re: namespace support requires network modules to say GPL
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_ 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_. 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/
Re: namespace support requires network modules to say GPL
Jiri Slaby [EMAIL PROTECTED] writes: On 12/02/2007 12:13 AM, Eric W. Biederman wrote: Mark Lord [EMAIL PROTECTED] writes: 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_. Only protocols call sk_alloc. and many want to do register_netdev(). I haven't even touched register_netdev. So what should they be using there ? What are you having problems with? It is hard to answer specific questions without a context. VMware vmnet. With a quick glance in that direction it appears to the result of a design bug in vmnet that they call sk_alloc at all, and someone seems to have found a work around in vmnet for this situation. My gut feel is that vmware should just use tun or tap (whichever is the appropriate one), and be done with it. 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/
Re: namespace support requires network modules to say GPL
Stephen Hemminger [EMAIL PROTECTED] writes: On Sat, 1 Dec 2007 11:17:36 -0800 Stephen Hemminger [EMAIL PROTECTED] wrote: Then init_net needs to be not GPL limited. Sorry, we need to allow non GPL network drivers. There is a fine line between keeping the binary seething masses from accessing random kernel functions, and allowing reasonable (but still non GPL) things like ndiswrapper to use network device interface. I spoke too soon earlier, ndiswrapper builds and loads against current 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again I don't give a damn, but the enterprise distro vendors certainly care. It looks like someone found a work around for vmware. As for proprietary VPN software, the one case that came of David Miller said we had sufficient alternatives in the kernel that he didn't care. We have to make a lot of changes to get the network namespaces complete. I don't have pity on any external code that breaks because they won't let me at their code. If it turns out the code that was broken was an unacknowledged derivative work and it can't be fixed I have even less pity on them. 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/
Re: namespace support requires network modules to say GPL
Stephen Hemminger wrote: On Sat, 1 Dec 2007 11:17:36 -0800 Stephen Hemminger [EMAIL PROTECTED] wrote: Then init_net needs to be not GPL limited. Sorry, we need to allow non GPL network drivers. There is a fine line between keeping the binary seething masses from accessing random kernel functions, and allowing reasonable (but still non GPL) things like ndiswrapper to use network device interface. I spoke too soon earlier, ndiswrapper builds and loads against current 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again I don't give a damn, but the enterprise distro vendors certainly care. ... Naw, enterprise (or any other) distro vendors shouldn't have any issues here, since they can just patch their kernels around any issues. But it looks like Eric has this one thought out well enough. Cheers -- 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/
Re: namespace support requires network modules to say GPL
On Sat, 01 Dec 2007 22:34:09 -0500 Mark Lord [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: On Sat, 1 Dec 2007 11:17:36 -0800 Stephen Hemminger [EMAIL PROTECTED] wrote: Then init_net needs to be not GPL limited. Sorry, we need to allow non GPL network drivers. There is a fine line between keeping the binary seething masses from accessing random kernel functions, and allowing reasonable (but still non GPL) things like ndiswrapper to use network device interface. I spoke too soon earlier, ndiswrapper builds and loads against current 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again I don't give a damn, but the enterprise distro vendors certainly care. ... Naw, enterprise (or any other) distro vendors shouldn't have any issues here, since they can just patch their kernels around any issues. But it looks like Eric has this one thought out well enough. So you are saying all this is not a problem, fine. Any affected parties can certainly lobby for themselves. But I suspect they all think the kernel community is a bunch of ... and will just ignore the problem. -- Stephen Hemminger [EMAIL PROTECTED] -- 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/
