Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregister table
> Is this a "binary only" driver or just a driver on par with the NVidia > that is just "GPL'ed but unreadable"? There are reasons the GPL carefully defines it "The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregister table
"Henning P. Schmiedehausen" wrote: > I had an interesting discussion with my brother-in-law at this > weekend: What is source code? The GPL covers this, if you're using it: "The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable." > What if there is really a warbled indivdual that can write a driver in > object code? Or at least in x86 assembler and then performs the magic > necessary to link it into the kernel? You may of course write a driver/program by "cat > file.o" and end up with a program with no source. The gpl says source is "the preferred form of the work for making modifications to it." So this object file does not work with the gpl because object files is not a preferred form for making modifications. This could change if programmers in general change to *prefer* editing .o files *instead* of working with source and compilers. Winning the lottery every time is more probable though... Source in any language, even assembly, qualify. But note the "preferred form", merely disassembling the object file is dubious. So is deliberately obfuscated source. > Is this a "binary only" driver or just a driver on par with the NVidia > that is just "GPL'ed but unreadable"? It is definitely binary only, as there is no source. That don't nullify your obligation to provide source though, so you can't distribute it under the GPL. Try reading /usr/share/common-licenses/GPL , it isn't that long and have many answers to such questions. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregister table
Henning P. Schmiedehausen wrote: I had an interesting discussion with my brother-in-law at this weekend: What is source code? The GPL covers this, if you're using it: The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. What if there is really a warbled indivdual that can write a driver in object code? Or at least in x86 assembler and then performs the magic necessary to link it into the kernel? You may of course write a driver/program by cat file.o and end up with a program with no source. The gpl says source is the preferred form of the work for making modifications to it. So this object file does not work with the gpl because object files is not a preferred form for making modifications. This could change if programmers in general change to *prefer* editing .o files *instead* of working with source and compilers. Winning the lottery every time is more probable though... Source in any language, even assembly, qualify. But note the preferred form, merely disassembling the object file is dubious. So is deliberately obfuscated source. Is this a binary only driver or just a driver on par with the NVidia that is just GPL'ed but unreadable? It is definitely binary only, as there is no source. That don't nullify your obligation to provide source though, so you can't distribute it under the GPL. Try reading /usr/share/common-licenses/GPL , it isn't that long and have many answers to such questions. Helge Hafting - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregister table
Is this a binary only driver or just a driver on par with the NVidia that is just GPL'ed but unreadable? There are reasons the GPL carefully defines it The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregister table
[EMAIL PROTECTED] said: > Consider a chunk of x86 instructions using a home-grown OS > abstraction layer, and drivers that implement that layer for both > Linux and any non-GPL operating system. The binary blob is obviously > not derived from Linux, and may in fact run without modification in a > BSD or Solaris/x86 kernel. > There is in fact just such a layer. It might not currently have the > features needed to implement TCP, but it could be extended as needed. Sounds like you're talking about UDI. I thought that had died the horrible slow death it deserved - only to be dusted off, redone in CPU-agnostic bytecode and called ACPI. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregister table
[EMAIL PROTECTED] said: Consider a chunk of x86 instructions using a home-grown OS abstraction layer, and drivers that implement that layer for both Linux and any non-GPL operating system. The binary blob is obviously not derived from Linux, and may in fact run without modification in a BSD or Solaris/x86 kernel. There is in fact just such a layer. It might not currently have the features needed to implement TCP, but it could be extended as needed. Sounds like you're talking about UDI. I thought that had died the horrible slow death it deserved - only to be dusted off, redone in CPU-agnostic bytecode and called ACPI. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregister table
On Thursday 07 June 2001 12:03, Henning P. Schmiedehausen wrote: > "David S. Miller" <[EMAIL PROTECTED]> writes: > >And my current understanding is that allowing proprietary > >reimplementations of the VM, VFS, and core networking, is not one of > >the things which is allowed. > > ...is wanted (by you and possibly Linus). Not ...is allowed. > > It _is_ already allowed. Someone can use the posted patch which is > GPL open source, put it into the kernel and use their proprietary > module. > > And this is legal according to the "Kernel GPL, Linus Torvalds > edition (TM)" which says "any loadable module can be binary only". > Not "only loadable modules which are drivers". It may not be the > intention but it is the fact. I seem to recall something about binary modules being ok as long as they stick to the published interface, which would let out binary-only extensions to core kernel functionality. This would seem to permit reimplementation. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregister table
On Thursday 07 June 2001 12:03, Henning P. Schmiedehausen wrote: David S. Miller [EMAIL PROTECTED] writes: And my current understanding is that allowing proprietary reimplementations of the VM, VFS, and core networking, is not one of the things which is allowed. ...is wanted (by you and possibly Linus). Not ...is allowed. It _is_ already allowed. Someone can use the posted patch which is GPL open source, put it into the kernel and use their proprietary module. And this is legal according to the Kernel GPL, Linus Torvalds edition (TM) which says any loadable module can be binary only. Not only loadable modules which are drivers. It may not be the intention but it is the fact. I seem to recall something about binary modules being ok as long as they stick to the published interface, which would let out binary-only extensions to core kernel functionality. This would seem to permit reimplementation. -- Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregister table
Richard Gooch wrote: > > David S. Miller writes: > > > > Matt D. Robinson writes: > > > > This allows people to make proprietary implementations of TCP under > > > > Linux. And we don't want this just as we don't want to add a way to > > > > allow someone to do a proprietary Linux VM. > > > > > > And if as Joe User I don't want Linux TCP, but Joe's TCP, they can't > > > do that (in a supportable way)? Are you saying Linux is, "do it my > > > way, or it's the highway"? > > Pardon my cynicism, but this reads more like "I'm an ACME Inc. and I > want to sell a proprietary TCP stack for Linux, please change Linux to > make this possible/easy". I doubt there are many Joe Users out there > who want to replace their TCP stack. I bet they would be much happier > to see patches go in which improve the performance of the generic > kernel. Maybe Joe's TCP slows things down by 200% for the average user, so it will never go into the kernel proper. However, it has one vital feature that Bob needs that the faster (normal) stack can't offer. Bob gains if he can make the choice. If the 200% slower and - some sum of $$ makes him choose Joes TCP, so be it. Joes TCP could be open source, or written by the devil himself, and the technical decision can still be made by Bob. Now, if there are legal issues with a proprietary loadable module, that may be another topic of discussion altogether. Is there any restriction on what kind of module you can load? For instance, suppose I write an ethernet driver that has a built in TCP/IP stack in it somehow? This may not be smart, but it is technically possible... > If it bothers you that Linux caters more the the users and less to the > vendors, then use another OS. We don't mind. The door is over there. > Please don't slam it on your way out. Don't spite potential users just in the hope that you might be able to spite a few companies too. There is no need for Joe's TCP to be non-open-source...a modular TCP stack might be a really good option for making $$ though support fees... If there is a need to keep certain (proprietary) code out of the kernel, let lawyers & public pressure do it, not overly broad technical restrictions. > > > If Joe's TCP is opensource, they are more than welcome to publish > > such changes. > > Yep. And then we can all benefit. Agreed. Ben -- Ben Greear <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregister table
Matt D. Robinson writes: > > This allows people to make proprietary implementations of TCP under > > Linux. And we don't want this just as we don't want to add a way to > > allow someone to do a proprietary Linux VM. > > And if as Joe User I don't want Linux TCP, but Joe's TCP, they can't > do that (in a supportable way)? Are you saying Linux is, "do it my > way, or it's the highway"? If Joe's TCP is opensource, they are more than welcome to publish such changes. The loadable module functionality allows proprietary binary-only drivers for devices, not binary-only proprietary reimplementations of core parts of the kernel. Ask Linus himself if you do not believe me and you think my position stinks. He's the person you have to convince in the end. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregister table
"David S. Miller" wrote: > > La Monte H.P. Yarroll writes: > > Matt D. Robinson writes: > > > Is there any way to add in the capability to _replace_ TCP with > > > your own, so you can use your own layer? > > ABSOLUTELY NOT! > > And I will never in my lifetime allow such a facility to be added to > the Linux kernel. Who's to say you will always own the stack in the Linux kernel, or have the right to make such a statement? > This allows people to make proprietary implementations of TCP under > Linux. And we don't want this just as we don't want to add a way to > allow someone to do a proprietary Linux VM. And if as Joe User I don't want Linux TCP, but Joe's TCP, they can't do that (in a supportable way)? Are you saying Linux is, "do it my way, or it's the highway"? Seems rather Microsoft-ish of an attitude, if you ask me. I think this is EXACTLY the reason why you run into companies like Caldera and Microsoft saying that Linux stifles innovation. You say, "Oh, we allow you to do whatever you want", and when someone really does want to do that in a way that works for open source and for proprietary/high-security developers, you slam the door in their face. Quite a shame. Take it easy, --Matt > Later, > David S. Miller > [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregister table
Thanks! I'm glad you like our code. This patch does allow you to override TCP with a new implementation for new connections and then back out safely to the old TCP later. I think the feature you are asking for (replace TCP for EXISTING connections) is quite dangerous. You COULD grub around in existing sock structures and replace the proto_ops, but that would not be enough. We are talking about a stateful protocol here--your "TCP2" module would have to safely extract the state of the existing TCP connections and replace the control functions all as an atomic operation...and then undo that at the end. What was the application you had in mind? The applications we have been playing with do not suffer greatly from having to start new connections. Matt D. Robinson writes: > Is there any way to add in the capability to _replace_ TCP with > your own, so you can use your own layer? I guess you could > inet_unregister_protosw() of the IPPROTO_TCP, but does that > address outstanding connections? I don't believe so ... > > It would be nice if your patch offered that capability. Nice > work, BTW -- not enough compliments go out on lkml these days. :) > > --Matt > > "La Monte H.P. Yarroll" wrote: > > > > Here is the register/unregister inet[6]_create() table patch revised > > for 2.4.5. We thank Dave Miller for his helpful feedback on earlier > > versions of this patch. > > > > DESCRIPTION > > This patch adds a mechanism for registering new IP transport protocols > > for the socket() system call. It replaces the hard-coded switch > > tables in inet_create() and inet6_create() with explicit data > > structures. > > > > The new calls are: > > voidinet_register_protosw(struct inet_protosw *p); > > voidinet_unregister_protosw(struct inet_protosw *p); > > voidinet6_register_protosw(struct inet_protosw *p); > > voidinet6_unregister_protosw(struct inet_protosw *p); > > > > This is the first of a series of proposed changes to support IP > > transport modules. > > > > MOTIVATION > > As part of the effort to create the Linux Kernel implementation of > > SCTP , we seek to make it > > possible to load a new IP transport protocol as a kernel module. > > > > It is already possible to register new address families. It is even > > possible to register new transport protocols with IP. However, in > > order to be able to open a socket with a new transport protocol, you > > must replace the whole AF_INET address family. > > > > In addition to SCTP, there are other protocols which could find it > > useful to be in a kernel module. For example, TCP extensions like TCP > > framing and TCP over satellite, multicast protocols, and RTP/ROHC > > (robust header compression). In general, support for IP transport > > modules makes transport layer experimentation easier. > > > > CHANGES SINCE sockreg2.4.3-04 > > We noticed that inet6_protocol_base went away in 2.4.5, so we changed > > our v6 initialization to parallel the inet6_protocol initialization. > > We now call inet6_register_protosw() from *v6_init() instead of having > > a static array of struct protosw's. Since other protocols depend on > > raw sockets (e.g. ICMP, IGMP, NDISC) we still register rawv6_protosw > > in inet6_init(). > > > > piggy (La Monte H.P. Yarroll) > > Karl O. Knutson > > > > PATCH FOLLOWS > > diff -u -r linux-2.4.5/include/asm-alpha/socket.h linux/include/asm-alpha/socket.h > > --- linux-2.4.5/include/asm-alpha/socket.h Sat Feb 3 13:26:44 2001 > > +++ linux/include/asm-alpha/socket.hMon Jun 4 11:11:30 2001 > > @@ -66,6 +66,7 @@ > > /* level. For writing rarp and */ > > /* other similar things on the */ > > /* user level. */ > > +#defineSOCK_MAX(SOCK_PACKET+1) > > #endif > > > > #endif /* _ASM_SOCKET_H */ > > diff -u -r linux-2.4.5/include/asm-arm/socket.h linux/include/asm-arm/socket.h > > --- linux-2.4.5/include/asm-arm/socket.hSat Feb 3 13:26:44 2001 > > +++ linux/include/asm-arm/socket.h Mon Jun 4 11:11:30 2001 > > @@ -58,6 +58,7 @@ > > /* level. For writing rarp and */ > > /* other similar things on the */ > > /* user level. */ > > +#defineSOCK_MAX(SOCK_PACKET+1) > > #endif > > > > #endif /* _ASM_SOCKET_H */ > > diff -u -r linux-2.4.5/include/asm-cris/socket.h linux/include/asm-cris/socket.h > > --- linux-2.4.5/include/asm-cris/socket.h Fri Apr 6 12:51:19 2001 > > +++ linux/include/asm-cris/socket.h Mon Jun 4 11:11:30 2001 > > @@ -59,6 +59,7 @@ > > /* level. For writing rarp and */ > > /* other similar
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregister table
Thanks! I'm glad you like our code. This patch does allow you to override TCP with a new implementation for new connections and then back out safely to the old TCP later. I think the feature you are asking for (replace TCP for EXISTING connections) is quite dangerous. You COULD grub around in existing sock structures and replace the proto_ops, but that would not be enough. We are talking about a stateful protocol here--your TCP2 module would have to safely extract the state of the existing TCP connections and replace the control functions all as an atomic operation...and then undo that at the end. What was the application you had in mind? The applications we have been playing with do not suffer greatly from having to start new connections. Matt D. Robinson writes: Is there any way to add in the capability to _replace_ TCP with your own, so you can use your own layer? I guess you could inet_unregister_protosw() of the IPPROTO_TCP, but does that address outstanding connections? I don't believe so ... It would be nice if your patch offered that capability. Nice work, BTW -- not enough compliments go out on lkml these days. :) --Matt La Monte H.P. Yarroll wrote: Here is the register/unregister inet[6]_create() table patch revised for 2.4.5. We thank Dave Miller for his helpful feedback on earlier versions of this patch. DESCRIPTION This patch adds a mechanism for registering new IP transport protocols for the socket() system call. It replaces the hard-coded switch tables in inet_create() and inet6_create() with explicit data structures. The new calls are: voidinet_register_protosw(struct inet_protosw *p); voidinet_unregister_protosw(struct inet_protosw *p); voidinet6_register_protosw(struct inet_protosw *p); voidinet6_unregister_protosw(struct inet_protosw *p); This is the first of a series of proposed changes to support IP transport modules. MOTIVATION As part of the effort to create the Linux Kernel implementation of SCTP www.sourceforge.net/projects/lksctp, we seek to make it possible to load a new IP transport protocol as a kernel module. It is already possible to register new address families. It is even possible to register new transport protocols with IP. However, in order to be able to open a socket with a new transport protocol, you must replace the whole AF_INET address family. In addition to SCTP, there are other protocols which could find it useful to be in a kernel module. For example, TCP extensions like TCP framing and TCP over satellite, multicast protocols, and RTP/ROHC (robust header compression). In general, support for IP transport modules makes transport layer experimentation easier. CHANGES SINCE sockreg2.4.3-04 We noticed that inet6_protocol_base went away in 2.4.5, so we changed our v6 initialization to parallel the inet6_protocol initialization. We now call inet6_register_protosw() from *v6_init() instead of having a static array of struct protosw's. Since other protocols depend on raw sockets (e.g. ICMP, IGMP, NDISC) we still register rawv6_protosw in inet6_init(). piggy (La Monte H.P. Yarroll) Karl O. Knutson PATCH FOLLOWS diff -u -r linux-2.4.5/include/asm-alpha/socket.h linux/include/asm-alpha/socket.h --- linux-2.4.5/include/asm-alpha/socket.h Sat Feb 3 13:26:44 2001 +++ linux/include/asm-alpha/socket.hMon Jun 4 11:11:30 2001 @@ -66,6 +66,7 @@ /* level. For writing rarp and */ /* other similar things on the */ /* user level. */ +#defineSOCK_MAX(SOCK_PACKET+1) #endif #endif /* _ASM_SOCKET_H */ diff -u -r linux-2.4.5/include/asm-arm/socket.h linux/include/asm-arm/socket.h --- linux-2.4.5/include/asm-arm/socket.hSat Feb 3 13:26:44 2001 +++ linux/include/asm-arm/socket.h Mon Jun 4 11:11:30 2001 @@ -58,6 +58,7 @@ /* level. For writing rarp and */ /* other similar things on the */ /* user level. */ +#defineSOCK_MAX(SOCK_PACKET+1) #endif #endif /* _ASM_SOCKET_H */ diff -u -r linux-2.4.5/include/asm-cris/socket.h linux/include/asm-cris/socket.h --- linux-2.4.5/include/asm-cris/socket.h Fri Apr 6 12:51:19 2001 +++ linux/include/asm-cris/socket.h Mon Jun 4 11:11:30 2001 @@ -59,6 +59,7 @@ /* level. For writing rarp and */ /* other similar things on the */ /* user level. */ +#defineSOCK_MAX
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregister table
David S. Miller wrote: La Monte H.P. Yarroll writes: Matt D. Robinson writes: Is there any way to add in the capability to _replace_ TCP with your own, so you can use your own layer? ABSOLUTELY NOT! And I will never in my lifetime allow such a facility to be added to the Linux kernel. Who's to say you will always own the stack in the Linux kernel, or have the right to make such a statement? This allows people to make proprietary implementations of TCP under Linux. And we don't want this just as we don't want to add a way to allow someone to do a proprietary Linux VM. And if as Joe User I don't want Linux TCP, but Joe's TCP, they can't do that (in a supportable way)? Are you saying Linux is, do it my way, or it's the highway? Seems rather Microsoft-ish of an attitude, if you ask me. I think this is EXACTLY the reason why you run into companies like Caldera and Microsoft saying that Linux stifles innovation. You say, Oh, we allow you to do whatever you want, and when someone really does want to do that in a way that works for open source and for proprietary/high-security developers, you slam the door in their face. Quite a shame. Take it easy, --Matt Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregister table
Matt D. Robinson writes: This allows people to make proprietary implementations of TCP under Linux. And we don't want this just as we don't want to add a way to allow someone to do a proprietary Linux VM. And if as Joe User I don't want Linux TCP, but Joe's TCP, they can't do that (in a supportable way)? Are you saying Linux is, do it my way, or it's the highway? If Joe's TCP is opensource, they are more than welcome to publish such changes. The loadable module functionality allows proprietary binary-only drivers for devices, not binary-only proprietary reimplementations of core parts of the kernel. Ask Linus himself if you do not believe me and you think my position stinks. He's the person you have to convince in the end. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregister table
Richard Gooch wrote: David S. Miller writes: Matt D. Robinson writes: This allows people to make proprietary implementations of TCP under Linux. And we don't want this just as we don't want to add a way to allow someone to do a proprietary Linux VM. And if as Joe User I don't want Linux TCP, but Joe's TCP, they can't do that (in a supportable way)? Are you saying Linux is, do it my way, or it's the highway? Pardon my cynicism, but this reads more like I'm an ACME Inc. and I want to sell a proprietary TCP stack for Linux, please change Linux to make this possible/easy. I doubt there are many Joe Users out there who want to replace their TCP stack. I bet they would be much happier to see patches go in which improve the performance of the generic kernel. Maybe Joe's TCP slows things down by 200% for the average user, so it will never go into the kernel proper. However, it has one vital feature that Bob needs that the faster (normal) stack can't offer. Bob gains if he can make the choice. If the 200% slower and - some sum of $$ makes him choose Joes TCP, so be it. Joes TCP could be open source, or written by the devil himself, and the technical decision can still be made by Bob. Now, if there are legal issues with a proprietary loadable module, that may be another topic of discussion altogether. Is there any restriction on what kind of module you can load? For instance, suppose I write an ethernet driver that has a built in TCP/IP stack in it somehow? This may not be smart, but it is technically possible... If it bothers you that Linux caters more the the users and less to the vendors, then use another OS. We don't mind. The door is over there. Please don't slam it on your way out. Don't spite potential users just in the hope that you might be able to spite a few companies too. There is no need for Joe's TCP to be non-open-source...a modular TCP stack might be a really good option for making $$ though support fees... If there is a need to keep certain (proprietary) code out of the kernel, let lawyers public pressure do it, not overly broad technical restrictions. If Joe's TCP is opensource, they are more than welcome to publish such changes. Yep. And then we can all benefit. Agreed. Ben -- Ben Greear [EMAIL PROTECTED] [EMAIL PROTECTED] President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
