[RFC/PATCH 1/2] in-kernel sockets API

[RFC/PATCH 1/2] in-kernel sockets API

[Sridhar Samudrala]

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)
+{
+	mm_segment_t oldfs = get_fs();
+	int err;
+
+	set_fs(KERNEL_DS);
+	err = sock->ops->ioctl(sock, cmd, arg);
+	set_fs(oldfs);
+	
+	return err;
+}
+
 /* ABI emulation layers need these two */
 EXPORT_SYMBOL(move_addr_to_kernel);
 EXPORT_SYMBOL(move_addr_to_user);
@@ -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);

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Stephen Hemminger]

On Mon, 12 Jun 2006 16:56:01 -0700
Sridhar Samudrala <sri@us.ibm.com> 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?

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Arnaldo Carvalho de Melo]

On 6/13/06, Stephen Hemminger <shemminger@osdl.org> wrote:
> On Mon, 12 Jun 2006 16:56:01 -0700
> Sridhar Samudrala <sri@us.ibm.com> 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?

I guess so, Sridhar, could you take this into account and resend?

Thanks,

- Arnaldo

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Brian F. G. Bidulock]

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.

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Jan Engelhardt]

>+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
-- 

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Sridhar Samudrala]

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

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Daniel Phillips]

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

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Brian F. G. Bidulock]

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?

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Chase Venters]

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

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Daniel Phillips]

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

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Brian F. G. Bidulock]

Chase,

On Tue, 13 Jun 2006, Chase Venters wrote:
> 
> 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.

I was really just using Daniel's words.  I am all too aware that kernel
APIs are unstable.  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).

> 
> 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).

And that would be fine if we were completely agnostic toward what was
included in mainline, but we are not.  A particular case in point that
I deal with are STREAMS modules.  STREAMS continues to be forbidden from
the tree.  Nevertheless, STREAMS has historically provided one of the
most widespread mechanisms for providing value-added drivers to branded
UNIX or embedded RTOS offerings.  As a result, a large body of existing
drivers are cut off from the tree regardless of their licensing terms.

(Note that these is seldom a question of derivation for these drivers as
they are fully functioning on other operating systems: branded UNIX or
embedded RTOS.)

> 
> 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.

Any open-source license not compatible with the GPL.  One that comes to
mind is OpenSolaris drivers.  I'm sure that there are others because there
are many license that qualify as open source licenses that are incompatible
with the GPL.  For example, pure BSD is incompatible with GPL.

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.  The second step is to jump through the hoops and over the
hurdles necessary to open what has been to date proprietary code that may
contain intellectual property issues across a number of organizations.

In adopting a policy that hinders this process, we, instead, discourage
opening of drivers and inclusion in mainline, rather than promoting it.

Sorry for the rant.

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Brian F. G. Bidulock]

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).

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Ben Greear]

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 <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Chase Venters]

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

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Chase Venters]

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

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Brian F. G. Bidulock]

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 AT&T rtp-lib
implementation (non-GPL compatible license) utilizing this kernel
interface for UDP socket access.

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Ben Greear]

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 <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Chase Venters]

On Tuesday 13 June 2006 19:17, Brian F. G. Bidulock wrote:
> 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 AT&T rtp-lib
> implementation (non-GPL compatible license) utilizing this kernel
> interface for UDP socket access.

I don't mean to be obtuse, but the "Non-exclusive Non-commercial Limited-use 
Source" license seems to make something like that have limited usefulness in 
general. That is -- unless one were to obtain a commercial license from AT&T, 
but then that starts falling into the domain of what is likely prohibited by 
the GPL (some sort of proprietary work actually _derived_ off the kernel 
rather than just supporting it in some way).

But I did ask for examples...

Thanks,
Chase

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Brian F. G. Bidulock]

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.

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Brian F. G. Bidulock]

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.

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Brian F. G. Bidulock]

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.

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Chase Venters]

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

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Brian F. G. Bidulock]

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.

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Chase Venters]

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

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Brian F. G. Bidulock]

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.

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Theodore Tso]

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

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Alan Cox]

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

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Brian F. G. Bidulock]

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.

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]

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 <laforge@gnumonks.org>          	        http://gnumonks.org/
============================================================================
We all know Linux is great...it does infinite loops in 5 seconds. -- Linus

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Erik Mouw]

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

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]

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 <laforge@gnumonks.org>          	        http://gnumonks.org/
============================================================================
We all know Linux is great...it does infinite loops in 5 seconds. -- Linus

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Daniel Phillips]

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

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Brian F. G. Bidulock]

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.

Re: [RFC/PATCH 1/2] in-kernel sockets API

[Sridhar Samudrala]

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