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 netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC/PATCH] SO_NO_CHECK for IPv6
David Schwartz [EMAIL PROTECTED] wrote: Regardless of whatever verifications your application is doing on the data, it is not checksumming the ports and that's what the pseudo-header is helping with. So what? We are in the case where the data has already gotten to him. If it got to him in error, he'll reject it anyway. The receive checksum check will only reject packets that he would reject anyway. That makes it needless. What if it goes to the wrong recipient who doesn't have the upper- level checksums? Since that's not him, he has no control over its policy and thus no ability to harm it or help it. This is the whole point, IPv6 unlike IPv4 does not have IP header checksums so the high-level needs to protect it by checksumming the pseudo-header. Exactly. But *he* doesn't need to check that checksum, given that he already got the packet, since he has an upper-level checksum. He is not saying that his reasoning applies to everyone, just that it applies to him. He is not talking about disabling the send checksum, but the receive checksum. He knows that he does not need it. DS - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC/PATCH] SO_NO_CHECK for IPv6
Regardless of whatever verifications your application is doing on the data, it is not checksumming the ports and that's what the pseudo-header is helping with. So what? We are in the case where the data has already gotten to him. If it got to him in error, he'll reject it anyway. The receive checksum check will only reject packets that he would reject anyway. That makes it needless. Of course, if the check is nearly free, there's no potential win, so no point in bothering. DS - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
