Re: Proper way to release binary driver?
Hello, I would like to thank everybody who replied to my question yesterday. There were a lot of good suggestions and examples for me to go and look at. The conclusion we had come to between ourselves here was already very similar to most things suggested, but we were running into some smaller problems that would make our release too difficult to use for most customers. And ofcourse, I have no realised that it is not enough to simply release your code under GPL. You need to tie in with the real kernel as soon as you can. Thanks again all for your help. -- bfn, wabbit IBM Global Services, UK AMS in Greenock, Scotland. " To err is human, but to really foul things up requires the root password. " - 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: Proper way to release binary driver?
> We had hoped that MODVERSIONS would allow us to provide a single (or at > most a few) binary driver. Kernels with even minor version numbers are > supposed to be stable (even if they are buggy) ie. not have wildly > changing kernel interfaces. They have a stable API. THe ABI thing is an irrelevance to free software. avoiding the ABI compatibility mess is one of the great things free software lets you do. Alan - 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: Proper way to release binary driver?
We had hoped that MODVERSIONS would allow us to provide a single (or at most a few) binary driver. Kernels with even minor version numbers are supposed to be stable (even if they are buggy) ie. not have wildly changing kernel interfaces. They have a stable API. THe ABI thing is an irrelevance to free software. avoiding the ABI compatibility mess is one of the great things free software lets you do. Alan - 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: Proper way to release binary driver?
Hello, I would like to thank everybody who replied to my question yesterday. There were a lot of good suggestions and examples for me to go and look at. The conclusion we had come to between ourselves here was already very similar to most things suggested, but we were running into some smaller problems that would make our release too difficult to use for most customers. And ofcourse, I have no realised that it is not enough to simply release your code under GPL. You need to tie in with the real kernel as soon as you can. Thanks again all for your help. -- bfn, wabbit IBM Global Services, UK AMS in Greenock, Scotland. " To err is human, but to really foul things up requires the root password. " - 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: Proper way to release binary driver?
On 04.06 Christopher Turcksin wrote: > > In practice, that doesn't work. A driver compiled with 2.2.16 doesn't > load with 2.2.16-5.0 (from RedHat 6.2) (just an example). > Thats is probably because RH 2.2.16-5.0 is not 2.2.16, but 2.2.17-pre-something. Due to the bad idea of distros to name kernels in its own way, you can never know which kernel are they giving if you do not read the changelog from rpm. For example, in Mandrake you get: werewolf:~/in# rpm -q --changelog kernel-smp | more * Thu Apr 05 2001 Chmouel Boudjnah <[EMAIL PROTECTED]> 2.4.3-8mdk - btt upgrade to 0.7.62. * Thu Apr 05 2001 Chmouel Boudjnah <[EMAIL PROTECTED]> 2.4.3-7mdk - 2.4.3-ac3. - Fix wait on psaux port (prumph). So my naming scheme would be: 2.4.3-7mdk -> 2.4.3-ac3-1mdk 2.4.3-8mdk -> 2.4.3-ac3-2mdk. An or release can have changed some important things from its stable parent, and should be evident which version is a kernel from its rpm name... I do not think that the other patches distros apply change important things, but correct bugs. So really you should only track the -preX and -acX releases from Linus and Alan. -- J.A. Magallon # Let the source mailto:[EMAIL PROTECTED] # be with you, Luke... Linux werewolf 2.4.3-ac3 #1 SMP Thu Apr 5 00:28:45 CEST 2001 i686 - 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: Proper way to release binary driver?
Hi, I'd take a look at how nvidia delivers the module for their video cards... http://www.nvidia.com/Products/Drivers.nsf/Linux.html you build the module with your current kernel or download the one for your distribution (limited number) 4-front tenchnologies has also done a long-term good job on this with oss joelja On Fri, 6 Apr 2001, Christopher Turcksin wrote: > "Eric W. Biederman" wrote: > > > If what you are after is a way to release a driver that is not a > > hassle to add to an already working system, you will find a more > > receptive ear. I have heard some talk, that it would be a good idea > > to figure out how to standardize how to compile a kernel driver > > outside the kernel tree, so it could be trivial enough that anyone > > could do it. To date there are enough people around who don't have > > problems compiling their own kernel that this hasn't become a major > > issue. > > Eric, > > I am finding myself exactly in this situation, and I've got a feeling > that this won't be the last time either. > > I expect that every future Linux driver I get involved with will be > released under GPL. However, I think that the majority of our customers > will be running a distribution that does not yet support a new driver, > and even at Linux speeds, it'll take a long enough time that customers > cannot afford to wait for the next release that includes the driver. > > So the big issue for us appears to be how we support these customers. > > There is no way that we can support customers who have custom kernels, > but since they are 'in it' enough to compile their own kernel, I guess > they're able to apply our patch and recompile it. I actually suspect > that there aren't that many who do this anyway. > > Where we find we have a problem is the number of different 'standard' > kernels out there. We find that we need to support all releases since > the last year or so for each distribution. And for each of those, we > find that there are many different kernel versions (some bugfixes, some > provide half a dozen different kernels with the CDs, aso.). And since we > do not expect these customers to compile their own kernel, we see no > option but to provide a precompiled binary driver. The numbers multiply > quickly and building all of those becomes an interesting problem. > > We had hoped that MODVERSIONS would allow us to provide a single (or at > most a few) binary driver. Kernels with even minor version numbers are > supposed to be stable (even if they are buggy) ie. not have wildly > changing kernel interfaces. > > In practice, that doesn't work. A driver compiled with 2.2.16 doesn't > load with 2.2.16-5.0 (from RedHat 6.2) (just an example). > > > > -- -- Joel Jaeggli [EMAIL PROTECTED] Academic User Services [EMAIL PROTECTED] PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- It is clear that the arm of criticism cannot replace the criticism of arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy of the right, 1843. - 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: Proper way to release binary driver?
Hi, I'd take a look at how nvidia delivers the module for their video cards... http://www.nvidia.com/Products/Drivers.nsf/Linux.html you build the module with your current kernel or download the one for your distribution (limited number) 4-front tenchnologies has also done a long-term good job on this with oss joelja On Fri, 6 Apr 2001, Christopher Turcksin wrote: "Eric W. Biederman" wrote: If what you are after is a way to release a driver that is not a hassle to add to an already working system, you will find a more receptive ear. I have heard some talk, that it would be a good idea to figure out how to standardize how to compile a kernel driver outside the kernel tree, so it could be trivial enough that anyone could do it. To date there are enough people around who don't have problems compiling their own kernel that this hasn't become a major issue. Eric, I am finding myself exactly in this situation, and I've got a feeling that this won't be the last time either. I expect that every future Linux driver I get involved with will be released under GPL. However, I think that the majority of our customers will be running a distribution that does not yet support a new driver, and even at Linux speeds, it'll take a long enough time that customers cannot afford to wait for the next release that includes the driver. So the big issue for us appears to be how we support these customers. There is no way that we can support customers who have custom kernels, but since they are 'in it' enough to compile their own kernel, I guess they're able to apply our patch and recompile it. I actually suspect that there aren't that many who do this anyway. Where we find we have a problem is the number of different 'standard' kernels out there. We find that we need to support all releases since the last year or so for each distribution. And for each of those, we find that there are many different kernel versions (some bugfixes, some provide half a dozen different kernels with the CDs, aso.). And since we do not expect these customers to compile their own kernel, we see no option but to provide a precompiled binary driver. The numbers multiply quickly and building all of those becomes an interesting problem. We had hoped that MODVERSIONS would allow us to provide a single (or at most a few) binary driver. Kernels with even minor version numbers are supposed to be stable (even if they are buggy) ie. not have wildly changing kernel interfaces. In practice, that doesn't work. A driver compiled with 2.2.16 doesn't load with 2.2.16-5.0 (from RedHat 6.2) (just an example). -- -- Joel Jaeggli [EMAIL PROTECTED] Academic User Services [EMAIL PROTECTED] PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- It is clear that the arm of criticism cannot replace the criticism of arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy of the right, 1843. - 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: Proper way to release binary driver?
On 04.06 Christopher Turcksin wrote: In practice, that doesn't work. A driver compiled with 2.2.16 doesn't load with 2.2.16-5.0 (from RedHat 6.2) (just an example). Thats is probably because RH 2.2.16-5.0 is not 2.2.16, but 2.2.17-pre-something. Due to the bad idea of distros to name kernels in its own way, you can never know which kernel are they giving if you do not read the changelog from rpm. For example, in Mandrake you get: werewolf:~/in# rpm -q --changelog kernel-smp | more * Thu Apr 05 2001 Chmouel Boudjnah [EMAIL PROTECTED] 2.4.3-8mdk - btt upgrade to 0.7.62. * Thu Apr 05 2001 Chmouel Boudjnah [EMAIL PROTECTED] 2.4.3-7mdk - 2.4.3-ac3. - Fix wait on psaux port (prumph). So my naming scheme would be: 2.4.3-7mdk - 2.4.3-ac3-1mdk 2.4.3-8mdk - 2.4.3-ac3-2mdk. An ac or pre release can have changed some important things from its stable parent, and should be evident which version is a kernel from its rpm name... I do not think that the other patches distros apply change important things, but correct bugs. So really you should only track the -preX and -acX releases from Linus and Alan. -- J.A. Magallon # Let the source mailto:[EMAIL PROTECTED] # be with you, Luke... Linux werewolf 2.4.3-ac3 #1 SMP Thu Apr 5 00:28:45 CEST 2001 i686 - 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/
