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
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 d
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
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 thi
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
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-st
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.
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 wast
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
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 contra
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 d
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 o
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
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 th
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"
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 pa
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 compa
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
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.
-
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 lic
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
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 tha
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 GP
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
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 b
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.
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 a
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);
+EX
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 th
>+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 "unsubsc
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);
> > +EXP
On 6/13/06, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
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 th
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
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 mov
34 matches
Mail list logo
