Re: [RFC/PATCH 1/2] in-kernel sockets API
Chase, On Tue, 13 Jun 2006, Chase Venters wrote: I don't think that it is fair to say that an unstable API/ABI, in of itself, provides an incentive to open an existing proprietary driver. Sure it does, depending on your perspective and what you're willing to consider. The lack of a stable API/ABI means that if you don't want to have to do work tracking the kernel, you should push to have your drivers merged. More work must be done to track the kernel before they are merged, thus purposeless API changes, or unnecessary use of EXPORT_SYMBOL_GPL impedes merging Not all useful kernel modules will nor should be merged GPL or not. I think that a policy that intentionally makes it hard for proprietary modules to be developed defeats the purpose of ultimate opening and merging. It might end up causing something like iBCS, LinuxABI, SVR D3DK, or ODI to flourish obviating the principal goal. The interface currently under discussion is ultimately derived from the BSD socket-protocol interface, and IMHO should be EXPORT_SYMBOL instead of EXPORT_SYMBOL_GPL, if only because using _GPL serves no purpose here and can be defeated with 3 or 4 obvious (and probably existing) lines of code. I wrote similar wrappers for STREAMS TPI to Linux NET4 interface instead of using pointers directly quite a few years ago. I doubt I was the first. There is nothing really so novel here that it deserves _GPL. - 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 1/2] in-kernel sockets API
On Wednesday 14 June 2006 01:06, Brian F. G. Bidulock wrote: The interface currently under discussion is ultimately derived from the BSD socket-protocol interface, and IMHO should be EXPORT_SYMBOL instead of EXPORT_SYMBOL_GPL, if only because using _GPL serves no purpose here and can be defeated with 3 or 4 obvious (and probably existing) lines of code. I wrote similar wrappers for STREAMS TPI to Linux NET4 interface instead of using pointers directly quite a few years ago. I doubt I was the first. There is nothing really so novel here that it deserves _GPL. I mentioned that I don't have any particular opinion on the BSD socket API in this discussion. All that I'm speaking of here is a property of licensing. I've watched a lot of what has happened with binary drivers. You'll find in the LKML archives plenty of lengthy discussions about whether or not binary drivers are allowed under the GPL. If I were to guess, there is still disagreement. Although some hardware support could improve, we thankfully seem to have some kind of an equilibrium capable of supporting lots of users. One point I remember coming up in the discussion was that the EXPORT_SYMBOL()/EXPORT_SYMBOL_GPL() split was a compromise of sorts. Interfaces that were needed to support users would reasonably be placed under EXPORT_SYMBOL(). By contrast, EXPORT_SYMBOL_GPL() would indicate functionality that would only seem to be used by derived works. It implies that any code using it should probably be GPL as well. I don't raise this in an attempt to belittle anything people are working on. It's an observation about the ecosystem - Linux in the 2.6 series has seen a great amount of corporate contribution in terms of enhancing what the kernel is capable of doing. GPL, I believe, encourages this. Thanks, Chase - 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 1/2] in-kernel sockets API
Chase, On Wed, 14 Jun 2006, Chase Venters wrote: One point I remember coming up in the discussion was that the EXPORT_SYMBOL()/EXPORT_SYMBOL_GPL() split was a compromise of sorts. Interfaces that were needed to support users would reasonably be placed under EXPORT_SYMBOL(). By contrast, EXPORT_SYMBOL_GPL() would indicate functionality that would only seem to be used by derived works. It implies that any code using it should probably be GPL as well. The difficulty with EXPORT_SYMBOL_GPL() as I see it that it reached farther than the GPL. GPL does not impact non-derived works, which can be licensed under any terms their authors see fit. Whereas, EXPORT_SYMBOL_GPL() requires a non-derived work to declare a GPL license to even use it. If you subscribe to the FSF view of derived work (just linking is a derivation) then I suppose you would support the EXPORT_SYMBOL_GPL(). IANAL, but I don't believe that TRIPS nor Berne Convention case law supports the FSF view. Linus' statements in the COPYING file take a different view: that simple use of a technical interface is not necessarily (in itself) derivation. Now, I understand the use of EXPORT_SYMBOL() vs. EXPORT_SYMBOL_GPL() to allow authors to differ on this idea. But, in the case in point, the function pointers can be accessed by merely including the appropriate header files. Changing a the wrapper access to them to EXPORT_SYMBOL_GPL() strikes me as similar to changing kmalloc() from EXPORT_SYMBOL() to EXPORT_SYMBOL_GPL(). Understand that all exported symbols, regardless of licensing or modversions or whatever, are available in the kernel boot image and can be linked to by any module at any time. That is, those that would abuse the concept of derivation will not be impeded by EXPORT_SYMBOL_GPL(). (Rip the symbol from the kernel image, write a thin GPL'ed module that aliases the symbol and the exports it again as EXPORT_SYMBOL() without module versioning, copy the lines of code into the proprietary module, reversing the order of arbitrary lines, etc.) In any case, all it serves to do is to punish honest non-derivative works not published compatible with the GPL. What I resist is the apparent attempt to change these symbols to _GPL as some matter of general policy in this case contrary to the author's original intentions as expressed in the original patch submission, and without the author of the interface being wrappered jumping up an screaming that his code was under strict FSF linking-is-derivation GPL (in which case we could have had a good discussion on whether Linux NET4 is actually a derivative work of BSD 4.4 Lite which was licensed under the old BSD license, incompatible with the GPL ;) As a general policy I would say make it EXPORT_SYMBOL() unless the author of the patch (derivation) or author of the original (derived) code dictates that it be EXPORT_SYMBOL_GPL(). Ok, I'll shut up now... ...really. - 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 1/2] in-kernel sockets API
Ar Mer, 2006-06-14 am 00:07 -0600, ysgrifennodd Brian F. G. Bidulock: I think that a policy that intentionally makes it hard for proprietary modules to be developed defeats the purpose of ultimate opening and merging. It isn't policy its called copyright law. The interface currently under discussion is ultimately derived from the BSD socket-protocol interface, and IMHO should be EXPORT_SYMBOL instead of EXPORT_SYMBOL_GPL, if only because using _GPL serves no purpose here and can be defeated with 3 or 4 obvious (and probably existing) lines of code You don't seem to understand copyright law either. The GPL like all copyright licenses deals with the right to make copies and to create and control derivative works. It's not defeated by four lines of code. I wrote similar wrappers for STREAMS TPI to Linux NET4 interface instead of using pointers directly quite a few years ago. I doubt I was the first. Is that a confession ;) There is nothing really so novel here that it deserves _GPL. Copyright is not about novelty, you have it confused with the theoretical (not actual) role of patents. Wrong kind of intellectual monopoly right. Alan - 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 1/2] in-kernel sockets API
On Tue, Jun 13, 2006 at 07:53:19PM -0500, Chase Venters wrote: It is the lack of an ABI that is most frustrating to these users. And the presence of an ABI would be _very_ frustrating to core developers. Not only would these people suffer, everyone would -- developer time would be wasted dealing with cruft, and forward progress would be slowed. Note that just because an interface is EXPORT_SYMBOL doesn't mean that the interface is guaranteed to be stable. So folks who are aruging that an interface shouldn't be usable by non-GPL applications because we are therefore guaranteeing a stable API are making an unwarranted assumption. - Ted - 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 1/2] in-kernel sockets API
Alan, On Wed, 14 Jun 2006, Alan Cox wrote: It isn't policy its called copyright law. I know that I said I'd shut up, but I missed in TRIPS where it said that symbols must be EXPORT_SYMBOL_GPL... Could you point that out? (Just kidding.) You don't seem to understand copyright law either. The GPL like all copyright licenses deals with the right to make copies and to create and control derivative works. It's not defeated by four lines of code. The 3 or 4 lines of code that I wrote as an original expression before the patch was submitted. Is that a confession ;) No, just a declaration: the code in question was released under GPL Version 2. Copyright is not about novelty, you have it confused with the theoretical (not actual) role of patents. Wrong kind of intellectual monopoly right. Yes, perhaps I should have said original instead of novel. The patch is not original as it was predated by equivalent (machine translatable) original expressions. - 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 1/2] in-kernel sockets API
On Tue, Jun 13, 2006 at 02:12:41PM -0700, Daniel Phillips wrote: This has the makings of a nice stable internal kernel api. Why do we want to provide this nice stable internal api to proprietary modules? because there is IMHO legally nothing we can do about it anyway. Use of an industry-standard API that is provided in multiple operating system is one of the clearest idnication of some program _not_ being a derivative work. Whether we like it or not, it doesn't really matter if we export them GPL-only or not. Anybody using those scoket API calls will be having an easy time arguing in favor of non-derivative work. The GPL doesn't extend beyon what copyright law allows you to do... -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ We all know Linux is great...it does infinite loops in 5 seconds. -- Linus pgpFWlVVgch8f.pgp Description: PGP signature
Re: [RFC/PATCH 1/2] in-kernel sockets API
On Wed, Jun 14, 2006 at 03:30:22PM +0200, Harald Welte wrote: On Tue, Jun 13, 2006 at 02:12:41PM -0700, Daniel Phillips wrote: This has the makings of a nice stable internal kernel api. Why do we want to provide this nice stable internal api to proprietary modules? because there is IMHO legally nothing we can do about it anyway. Use of an industry-standard API that is provided in multiple operating system is one of the clearest idnication of some program _not_ being a derivative work. IMHO there is no industry-standard API for in-kernel use of sockets. There is however one for user space. Erik (IANAL, etc) -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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 1/2] in-kernel sockets API
On Wed, Jun 14, 2006 at 04:29:04PM +0200, Erik Mouw wrote: On Wed, Jun 14, 2006 at 03:30:22PM +0200, Harald Welte wrote: On Tue, Jun 13, 2006 at 02:12:41PM -0700, Daniel Phillips wrote: This has the makings of a nice stable internal kernel api. Why do we want to provide this nice stable internal api to proprietary modules? because there is IMHO legally nothing we can do about it anyway. Use of an industry-standard API that is provided in multiple operating system is one of the clearest idnication of some program _not_ being a derivative work. IMHO there is no industry-standard API for in-kernel use of sockets. There is however one for user space. it doesn't matter in what space you are. If the API really is similar enough, then any piece of code (no matter where it was originally intended to run) will be able to work with any such socket API. The whole point of this is: Where is the derivation of an existing work? I can write a program against some BSD socket api somewhere, and I can easily make it use the proposed in-kernel sockets API. No derivation of anything that is inside the kernel and GPL licensed. (IANAL, etc) Neither am I, but I'm constantly dealing with legal questions related to the GPL while running gpl-violations.org. -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ We all know Linux is great...it does infinite loops in 5 seconds. -- Linus pgpIzJfnLL2Vq.pgp Description: PGP signature
Re: [RFC/PATCH 1/2] in-kernel sockets API
Hi Harald, You wrote: On Tue, Jun 13, 2006 at 02:12:41PM -0700, I wrote: This has the makings of a nice stable internal kernel api. Why do we want to provide this nice stable internal api to proprietary modules? because there is IMHO legally nothing we can do about it anyway. Speaking as a former member of a grey market binary module vendor that came in from the cold I can assure you that the distinction between EXPORT and EXPORT_GPL _is_ meaningful. That tainted flag makes it extremely difficult to do deals with mainstream Linux companies and there is always the fear that it will turn into a legal problem. The latter bit tends to make venture capitalists nervous. That said, the EXPORT_GPL issue is not about black and white legal issues, it is about gentle encouragement. In this case we are offering a clumsy, on-the-metal, guaranteed-to-change-and-make-you-edit-code interface to non-GPL-compatible modules and a decent, stable (in the deserves to live sense) interface for the pure of heart. Gentle encouragement at exactly the right level. Did we settle the question of whether these particular exports should be EXPORT_SYMBOL_GPL? Regards, Daniel - 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 1/2] in-kernel sockets API
Daniel, On Wed, 14 Jun 2006, Daniel Phillips wrote: Speaking as a former member of a grey market binary module vendor that came in from the cold I can assure you that the distinction between EXPORT and EXPORT_GPL _is_ meaningful. That tainted flag makes it extremely difficult to do deals with mainstream Linux companies and there is always the fear that it will turn into a legal problem. The latter bit tends to make venture capitalists nervous. EXPORT_SYMBOL_GPL and the Tainted flag have nothing to do with each other. - 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 1/2] in-kernel sockets API
On Wed, 2006-06-14 at 10:48 -0700, Daniel Phillips wrote: Did we settle the question of whether these particular exports should be EXPORT_SYMBOL_GPL? When i submitted this patch, i didn't really think about the different ways to export these symbols. I simply used the EXPORT_SYMBOL() that is used by all the other exports in net/socket.c including kernel_sendmsg() and kernel_recvmsg(). I am OK with either option(EXPORT_SYMBOL or EXPORT_SYMBOL_GPL) and i will leave it to David Miller to make that decision at this point. Thanks Sridhar - 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 1/2] in-kernel sockets API
Stephen, On Tue, 13 Jun 2006, Stephen Hemminger wrote: @@ -2176,3 +2279,13 @@ EXPORT_SYMBOL(sock_wake_async); EXPORT_SYMBOL(sockfd_lookup); EXPORT_SYMBOL(kernel_sendmsg); EXPORT_SYMBOL(kernel_recvmsg); +EXPORT_SYMBOL(kernel_bind); +EXPORT_SYMBOL(kernel_listen); +EXPORT_SYMBOL(kernel_accept); +EXPORT_SYMBOL(kernel_connect); +EXPORT_SYMBOL(kernel_getsockname); +EXPORT_SYMBOL(kernel_getpeername); +EXPORT_SYMBOL(kernel_getsockopt); +EXPORT_SYMBOL(kernel_setsockopt); +EXPORT_SYMBOL(kernel_sendpage); +EXPORT_SYMBOL(kernel_ioctl); Don't we want to restrict this to GPL code with EXPORT_SYMBOL_GPL? There are direct derivatives of the BSD/POSIX system call interface. The protocol function pointers within the socket structure are not GPL only. Why make this wrappered access to them GPL only? It will only encourange the reverse of what they were intended to do: be used instead of the protocol function pointers within the socket structure, that currently carry no such restriction. - 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 1/2] in-kernel sockets API
+extern int kernel_ioctl(struct socket *sock, int cmd, unsigned long arg); + I would prefer naming it kernel_sock_ioctl, since (general) ioctl often done on fds (or struct file * for that matter) rather than sockets. Jan Engelhardt -- - 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 1/2] in-kernel sockets API
On Tue, 2006-06-13 at 16:58 +0200, Jan Engelhardt wrote: +extern int kernel_ioctl(struct socket *sock, int cmd, unsigned long arg); + I would prefer naming it kernel_sock_ioctl, since (general) ioctl often done on fds (or struct file * for that matter) rather than sockets. I agree that this is misleading. My original preference was to use ksock_ prefix for all these wrapper functions. But just to be consistent with the existing kernel_sendmsg and kernel_recvmsg, i used kernel_ prefix. If it is OK, i could rename them also to use the ksock_ prefix to make them all consistent and also indicating that we are operating on sockets. If not, i will go with kernel_sock_ioctl(). Thanks Sridhar - 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 1/2] in-kernel sockets API
Brian F. G. Bidulock wrote: Stephen, On Tue, 13 Jun 2006, Stephen Hemminger wrote: @@ -2176,3 +2279,13 @@ EXPORT_SYMBOL(sock_wake_async); EXPORT_SYMBOL(sockfd_lookup); EXPORT_SYMBOL(kernel_sendmsg); EXPORT_SYMBOL(kernel_recvmsg); +EXPORT_SYMBOL(kernel_bind); +EXPORT_SYMBOL(kernel_listen); +EXPORT_SYMBOL(kernel_accept); +EXPORT_SYMBOL(kernel_connect); +EXPORT_SYMBOL(kernel_getsockname); +EXPORT_SYMBOL(kernel_getpeername); +EXPORT_SYMBOL(kernel_getsockopt); +EXPORT_SYMBOL(kernel_setsockopt); +EXPORT_SYMBOL(kernel_sendpage); +EXPORT_SYMBOL(kernel_ioctl); Don't we want to restrict this to GPL code with EXPORT_SYMBOL_GPL? There are direct derivatives of the BSD/POSIX system call interface. The protocol function pointers within the socket structure are not GPL only. Why make this wrappered access to them GPL only? It will only encourange the reverse of what they were intended to do: be used instead of the protocol function pointers within the socket structure, that currently carry no such restriction. This has the makings of a nice stable internal kernel api. Why do we want to provide this nice stable internal api to proprietary modules? Regards, Daniel - 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 1/2] in-kernel sockets API
Daniel, On Tue, 13 Jun 2006, Daniel Phillips wrote: This has the makings of a nice stable internal kernel api. Why do we want to provide this nice stable internal api to proprietary modules? Why not? Not all non-GPL modules are proprietary. Do we lose something by making a nice stable api available to non-derived modules? - 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 1/2] in-kernel sockets API
On Tue, 13 Jun 2006, Brian F. G. Bidulock wrote: Daniel, On Tue, 13 Jun 2006, Daniel Phillips wrote: This has the makings of a nice stable internal kernel api. Why do we want to provide this nice stable internal api to proprietary modules? Why not? Not all non-GPL modules are proprietary. Do we lose something by making a nice stable api available to non-derived modules? Look out for that word (stable). Judging from history (and sanity), arguing /in favor of/ any kind of stable module API is asking for it. At least some of us feel like stable module APIs should be explicitly discouraged, because we don't want to offer comfort for code that refuses to live in the tree (since getting said code into the tree is often a goal). I'm curious now too - can you name some non-GPL non-proprietary modules we should be concerned about? I'd think most of the possible examples (not sure what they are) would be better off dual-licensed (one license being GPL) and in-kernel. Thanks, Chase - 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 1/2] in-kernel sockets API
Chase Venters wrote: can you name some non-GPL non-proprietary modules we should be concerned about? You probably meant non-GPL-compatible non-proprietary. If so, then by definition there are none. Regards, Daniel - 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 1/2] in-kernel sockets API
Chase Venters wrote: At least some of us feel like stable module APIs should be explicitly discouraged, because we don't want to offer comfort for code that refuses to live in the tree (since getting said code into the tree is often a goal). Some of us write modules for specific features that are not wanted in the mainline kernel, even though they are pure GPL. Our life is hard enough with out people setting out to deliberately make things more difficult! Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - 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 1/2] in-kernel sockets API
On Tuesday 13 June 2006 17:46, Brian F. G. Bidulock wrote: Daniel, On Tue, 13 Jun 2006, Daniel Phillips wrote: You probably meant non-GPL-compatible non-proprietary. If so, then by definition there are none. Well, being GPL compatible is not a requirement for an open source license. IANAL, but last I checked, pure-BSD is not compatible with GPL (it actually has to be dual-licensed BSD/GPL). It depends on what you mean by pure-BSD. If you're talking about the 4-clause license with the advertising clause, then you are correct. Otherwise (IANAL) but my understanding is that BSD code can even be relicensed GPL by a third party contribution (though it is perhaps kind to ask for relicensing permission anyway). From your other message: To some it is a serious failing of Linux (particularly those involved in porting kernel modules from branded UNIX or embedded RTOS). To those whatever stability that can be offered is a boon. To those, even worse is the lack of an ABI (even for a single kernel version). Then would offering a 'stable API in disguise' not be a disaster and an irritation to these people? If the kernel doesn't specify that an in-kernel interface is stable, then there is no reason to expect it to be. It might not change, but there won't be too much sympathy for out-of-tree users if it does. The kernel comes with big warnings about the lack of a stable API for a reason. Another thing to consider is that the first step for many organizations in opening a driver under GPL is to release a proprietary module that at least first works. If the driver is an old-tech Linux port, then it seems there isn't too much stopping them from doing this today (aside from the fact that some people think proprietary modules are murky anyway). In this case, we don't want a stable API/ABI, because then we leave them with little incentive to open the code. And if the driver is new code, they're better off doing an open driver from the start (especially since writing a driver _for_ Linux, as opposed to porting one, might make it count as 'derived' and hence unlawful unless released GPL). Sorry for the rant. We're not as perfect as I wish we were. But the lack of stable API (dead horse) is something that is fairly well established and understood. I think most people feel that the cost-benefit analysis, for Linux anyway, strongly favors no stable API. Thanks, Chase - 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 1/2] in-kernel sockets API
On Tuesday 13 June 2006 18:42, Ben Greear wrote: Chase Venters wrote: At least some of us feel like stable module APIs should be explicitly discouraged, because we don't want to offer comfort for code that refuses to live in the tree (since getting said code into the tree is often a goal). Some of us write modules for specific features that are not wanted in the mainline kernel, even though they are pure GPL. Our life is hard enough with out people setting out to deliberately make things more difficult! Fair enough, but if you are doing out of tree, pure GPL modules, EXPORT_SYMBOL_GPL() isn't a bad thing, is it? Don't mistake me for actually having a big opinion specifically about this socket API's usage of EXPORT_SYMBOL()... just raising some points that I think apply to these decisions in general. I don't really see a compelling reason for EXPORT_SYMBOL() over EXPORT_SYMBOL_GPL() on the socket APIs though... I'm trying to imagine what kind of legitimate non-GPL modules might use them. Ben Thanks, Chase - 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 1/2] in-kernel sockets API
Chase, On Tue, 13 Jun 2006, Chase Venters wrote: I'm trying to imagine what kind of legitimate non-GPL modules might use them. Example: in-kernel RTP implementation derived from ATT rtp-lib implementation (non-GPL compatible license) utilizing this kernel interface for UDP socket access. - 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 1/2] in-kernel sockets API
Chase Venters wrote: On Tuesday 13 June 2006 18:42, Ben Greear wrote: Chase Venters wrote: At least some of us feel like stable module APIs should be explicitly discouraged, because we don't want to offer comfort for code that refuses to live in the tree (since getting said code into the tree is often a goal). Some of us write modules for specific features that are not wanted in the mainline kernel, even though they are pure GPL. Our life is hard enough with out people setting out to deliberately make things more difficult! Fair enough, but if you are doing out of tree, pure GPL modules, EXPORT_SYMBOL_GPL() isn't a bad thing, is it? Don't mistake me for actually having a big opinion specifically about this socket API's usage of EXPORT_SYMBOL()... just raising some points that I think apply to these decisions in general. I don't really see a compelling reason for EXPORT_SYMBOL() over EXPORT_SYMBOL_GPL() on the socket APIs though... I'm trying to imagine what kind of legitimate non-GPL modules might use them. I got to the flame war late and only saw your comment that stable API should be discouraged. That kind of thinking pisses me off because it assumes all modules out of the tree are that way because the authors want them out of the tree. I also understand that sometimes API needs to change, but please don't encourage change just to punish other authors, be they proprietary or otherwise. As for what type of EXPORT macro to use I surely don't have anything to say that hasn't been said multiple times before. Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - 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 1/2] in-kernel sockets API
Chase, On Tue, 13 Jun 2006, Chase Venters wrote: It depends on what you mean by pure-BSD. If you're talking about the 4-clause license with the advertising clause, then you are correct. Otherwise (IANAL) but my understanding is that BSD code can even be relicensed GPL by a third party contribution (though it is perhaps kind to ask for relicensing permission anyway). Yes, and the long list of open source licenses listed on the FSF website as incompatible with the GPL. Then would offering a 'stable API in disguise' not be a disaster and an irritation to these people? If the kernel doesn't specify that an in-kernel interface is stable, then there is no reason to expect it to be. It might not change, but there won't be too much sympathy for out-of-tree users if it does. The kernel comes with big warnings about the lack of a stable API for a reason. In fact most core kernel facilities (spin lock, memory caches, character and block device interface, even core file system) have had a very stable API (way back to early 2.4 kernels). An in fact most of them are derived from some variant or precursor to UNIX. For example, memory caches are a Sun Solaris concept. It is the lack of an ABI that is most frustrating to these users. Another thing to consider is that the first step for many organizations in opening a driver under GPL is to release a proprietary module that at least first works. If the driver is an old-tech Linux port, then it seems there isn't too much stopping them from doing this today (aside from the fact that some people think proprietary modules are murky anyway). In this case, we don't want a stable API/ABI, because then we leave them with little incentive to open the code. old-tech? No, these are high-tech drivers supported by commercial RTOS, from which Linux stands to benefit. And, by not allowing these organizations to take the first step (generate a workable Linux driver) such a policy provides them little incentive to ever move the driver to Linux, and cuts them off from opening it. I don't think that it is fair to say that an unstable API/ABI, in of itself, provides an incentive to open an existing proprietary driver. We're not as perfect as I wish we were. But the lack of stable API (dead horse) is something that is fairly well established and understood. I think most people feel that the cost-benefit analysis, for Linux anyway, strongly favors no stable API. Well, the lack of a stable ABI is well known. The API is largely stable (but not sacrosanctly so) for the major reason that changing it within a large code base is difficult and error prone at best. - 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 1/2] in-kernel sockets API
Chase, On Tue, 13 Jun 2006, Chase Venters wrote: But I did ask for examples... Perhaps the license isn't a good example, but there are other RTP stacks that are non-GPL compatible. Also, if it includes SSL code for SRTP, SSL license happens to be non-GPL compatible. - 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 1/2] in-kernel sockets API
Ben, On Tue, 13 Jun 2006, Ben Greear wrote: I got to the flame war late ... I think we're trying to have an honest open discussion here. I certainly don't mean to flame anyone and apologize if my remarks have been taken so. - 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 1/2] in-kernel sockets API
On Tuesday 13 June 2006 19:30, Brian F. G. Bidulock wrote: Yes, and the long list of open source licenses listed on the FSF website as incompatible with the GPL. Conceded, I suppose. The usage of EXPORT_SYMBOL() though tends to be for the reason of enabling drivers to offer functionality to the kernel -- not for people who want to turn the kernel into applications. (Consider for example how netfilter is exposed as GPL. You can build applications [routers] out of it, but in that case you're doing a work derived off of Linux, and you should be abiding by its GPL licensing terms) Then would offering a 'stable API in disguise' not be a disaster and an irritation to these people? If the kernel doesn't specify that an in-kernel interface is stable, then there is no reason to expect it to be. It might not change, but there won't be too much sympathy for out-of-tree users if it does. The kernel comes with big warnings about the lack of a stable API for a reason. In fact most core kernel facilities (spin lock, memory caches, character and block device interface, even core file system) have had a very stable API (way back to early 2.4 kernels). An in fact most of them are derived from some variant or precursor to UNIX. For example, memory caches are a Sun Solaris concept. I'm not advocating changing the API for no reason / just to piss off out of tree developers. I'm just trying to make clear that in these cases, 'stable' is just an observation -- not something you can count on. It is the lack of an ABI that is most frustrating to these users. And the presence of an ABI would be _very_ frustrating to core developers. Not only would these people suffer, everyone would -- developer time would be wasted dealing with cruft, and forward progress would be slowed. Another thing to consider is that the first step for many organizations in opening a driver under GPL is to release a proprietary module that at least first works. If the driver is an old-tech Linux port, then it seems there isn't too much stopping them from doing this today (aside from the fact that some people think proprietary modules are murky anyway). In this case, we don't want a stable API/ABI, because then we leave them with little incentive to open the code. old-tech? No, these are high-tech drivers supported by commercial RTOS, from which Linux stands to benefit. And, by not allowing these organizations to take the first step (generate a workable Linux driver) such a policy provides them little incentive to ever move the driver to Linux, and cuts them off from opening it. Perhaps another term may have been more appropriate. What I mean by 'old tech' is more 'existing code' -- ie, something you would port. And these organizations _are_ afforded the opportunity to take the first step -- that's why interfaces critical to drivers are currently EXPORT_SYMBOL(). I don't think that it is fair to say that an unstable API/ABI, in of itself, provides an incentive to open an existing proprietary driver. Sure it does, depending on your perspective and what you're willing to consider. The lack of a stable API/ABI means that if you don't want to have to do work tracking the kernel, you should push to have your drivers merged. We're not as perfect as I wish we were. But the lack of stable API (dead horse) is something that is fairly well established and understood. I think most people feel that the cost-benefit analysis, for Linux anyway, strongly favors no stable API. Well, the lack of a stable ABI is well known. The API is largely stable (but not sacrosanctly so) for the major reason that changing it within a large code base is difficult and error prone at best. Perhaps, but calling it 'stable' in any sense other than idle observation is a disaster, because the idea leads to pain and suffering when you do have a major reason to change the API. Thanks, Chase - 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
[RFC/PATCH 1/2] in-kernel sockets API
This patch makes it convenient to use the sockets API by the in-kernel
users like sunrpc, cifs ocfs2 etc and any future users.
Currently they get to this API by directly accesing the function pointers
in the sock structure.
Most of these functions are pretty simple and can be made inline and moved
to linux/net.h.
I used kernel_ prefix for this API to match with the existing kernel_sendmsg
and kernel_recvmsg() although i would prefer ksock_.
I have updated sunrpc to use this API.
I would appreciate any comments or suggestions for improvements.
Thanks
Sridhar
diff --git a/include/linux/net.h b/include/linux/net.h
index 84a490e..b70c28f 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -208,6 +208,25 @@ extern int kernel_recvmsg(struct
struct kvec *vec, size_t num,
size_t len, int flags);
+extern int kernel_bind(struct socket *sock, struct sockaddr *addr,
+ int addrlen);
+extern int kernel_listen(struct socket *sock, int backlog);
+extern int kernel_accept(struct socket *sock, struct socket **newsock,
+int flags);
+extern int kernel_connect(struct socket *sock, struct sockaddr *addr,
+ int addrlen, int flags);
+extern int kernel_getsockname(struct socket *sock, struct sockaddr *addr,
+ int *addrlen);
+extern int kernel_getpeername(struct socket *sock, struct sockaddr *addr,
+ int *addrlen);
+extern int kernel_getsockopt(struct socket *sock, int level, int optname,
+char *optval, int *optlen);
+extern int kernel_setsockopt(struct socket *sock, int level, int optname,
+char *optval, int optlen);
+extern int kernel_sendpage(struct socket *sock, struct page *page, int offset,
+ size_t size, int flags);
+extern int kernel_ioctl(struct socket *sock, int cmd, unsigned long arg);
+
#ifndef CONFIG_SMP
#define SOCKOPS_WRAPPED(name) name
#define SOCKOPS_WRAP(name, fam)
diff --git a/net/socket.c b/net/socket.c
index 02948b6..8f36be7 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -2160,6 +2160,109 @@ static long compat_sock_ioctl(struct fil
}
#endif
+int kernel_bind(struct socket *sock, struct sockaddr *addr, int addrlen)
+{
+ return sock-ops-bind(sock, addr, addrlen);
+}
+
+int kernel_listen(struct socket *sock, int backlog)
+{
+ return sock-ops-listen(sock, backlog);
+}
+
+int kernel_accept(struct socket *sock, struct socket **newsock, int flags)
+{
+ struct sock *sk = sock-sk;
+ int err;
+
+ err = sock_create_lite(sk-sk_family, sk-sk_type, sk-sk_protocol,
+ newsock);
+ if (err 0)
+ goto done;
+
+ err = sock-ops-accept(sock, *newsock, flags);
+ if (err 0) {
+ sock_release(*newsock);
+ goto done;
+ }
+
+ (*newsock)-ops = sock-ops;
+
+done:
+ return err;
+}
+
+int kernel_connect(struct socket *sock, struct sockaddr *addr, int addrlen,
+ int flags)
+{
+ return sock-ops-connect(sock, addr, addrlen, flags);
+}
+
+int kernel_getsockname(struct socket *sock, struct sockaddr *addr,
+int *addrlen)
+{
+ return sock-ops-getname(sock, addr, addrlen, 0);
+}
+
+int kernel_getpeername(struct socket *sock, struct sockaddr *addr,
+int *addrlen)
+{
+ return sock-ops-getname(sock, addr, addrlen, 1);
+}
+
+int kernel_getsockopt(struct socket *sock, int level, int optname,
+ char *optval, int *optlen)
+{
+ mm_segment_t oldfs = get_fs();
+ int err;
+
+ set_fs(KERNEL_DS);
+ if (level == SOL_SOCKET)
+ err = sock_getsockopt(sock, level, optname, optval, optlen);
+ else
+ err = sock-ops-getsockopt(sock, level, optname, optval,
+ optlen);
+ set_fs(oldfs);
+ return err;
+}
+
+int kernel_setsockopt(struct socket *sock, int level, int optname,
+ char *optval, int optlen)
+{
+ mm_segment_t oldfs = get_fs();
+ int err;
+
+ set_fs(KERNEL_DS);
+ if (level == SOL_SOCKET)
+ err = sock_setsockopt(sock, level, optname, optval, optlen);
+ else
+ err = sock-ops-setsockopt(sock, level, optname, optval,
+ optlen);
+ set_fs(oldfs);
+ return err;
+}
+
+int kernel_sendpage(struct socket *sock, struct page *page, int offset,
+ size_t size, int flags)
+{
+ if (sock-ops-sendpage)
+ return sock-ops-sendpage(sock, page, offset, size, flags);
+
+ return sock_no_sendpage(sock, page, offset, size, flags);
+}
+
+int kernel_ioctl(struct socket *sock, int cmd, unsigned long arg)
+{
+
Re: [RFC/PATCH 1/2] in-kernel sockets API
On Mon, 12 Jun 2006 16:56:01 -0700 Sridhar Samudrala [EMAIL PROTECTED] wrote: This patch makes it convenient to use the sockets API by the in-kernel users like sunrpc, cifs ocfs2 etc and any future users. Currently they get to this API by directly accesing the function pointers in the sock structure. Most of these functions are pretty simple and can be made inline and moved to linux/net.h. ... @@ -2176,3 +2279,13 @@ EXPORT_SYMBOL(sock_wake_async); EXPORT_SYMBOL(sockfd_lookup); EXPORT_SYMBOL(kernel_sendmsg); EXPORT_SYMBOL(kernel_recvmsg); +EXPORT_SYMBOL(kernel_bind); +EXPORT_SYMBOL(kernel_listen); +EXPORT_SYMBOL(kernel_accept); +EXPORT_SYMBOL(kernel_connect); +EXPORT_SYMBOL(kernel_getsockname); +EXPORT_SYMBOL(kernel_getpeername); +EXPORT_SYMBOL(kernel_getsockopt); +EXPORT_SYMBOL(kernel_setsockopt); +EXPORT_SYMBOL(kernel_sendpage); +EXPORT_SYMBOL(kernel_ioctl); Don't we want to restrict this to GPL code with EXPORT_SYMBOL_GPL? - 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
