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
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
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,
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
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
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
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
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
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
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
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
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
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);
+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
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
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);
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
30 matches
Mail list logo
