I have the need to distribute a binary-only driver (no flames, please), but
I am not certain how to build it so that it can be used on multiple kernel
versions. (Or is this impossible?)
I didn't find any "HOWTO (or recommendation) for proper binary-only driver
release etiquette", so if there are some preferred means, please let me
know.
I specifically had issues with the whole MODVERSIONS thing. I can include
<linux/verion.h> and <linux/config.h> to get the right CONFIG_MODVERSIONS
macro definitions, and then include <linux/modversions.h> as appropriate.
The end result is a driver with symbols whose names are mangled to match the
modversion-enabled mangling of a modversion-enabled kernel. This is good if
I release on the same kernel version.
Obviously, if I use a different kernel the module refuses to load. My first
guess was to get rid of the module-versioning stuff so that the symbols are
not mangled, and this seems to work, except that I must use insmod -f module
for kernels with a different version than what I built with.
So, if there are guides that I didn't find, or ones on this list that
someone things I should use, please let me know. Or at least comment on my
chosen way of doing things. It's this sort of thing that reinforces a
source form driver is the way to release stuff--then it can be built
alongside the user's kernel tree...
Please cc: me as I am not subscribed.
Brendan Miller
Dialogic, An Intel Company
"Miller, Brendan" <[email protected]> writes:
> I have the need to distribute a binary-only driver (no flames, please), but
> I am not certain how to build it so that it can be used on multiple kernel
> versions. (Or is this impossible?)
It's possible but frowned on. As a general rule any problem that occurs
in a system with a binary only driver, you will be called for support. Because
there is no easy way for the normal kernel developers to rule out your
code is not doing something nasty.
> I didn't find any "HOWTO (or recommendation) for proper binary-only driver
> release etiquette", so if there are some preferred means, please let me
> know.
>
> I specifically had issues with the whole MODVERSIONS thing. I can include
> <linux/verion.h> and <linux/config.h> to get the right CONFIG_MODVERSIONS
> macro definitions, and then include <linux/modversions.h> as appropriate.
> The end result is a driver with symbols whose names are mangled to match the
> modversion-enabled mangling of a modversion-enabled kernel. This is good if
> I release on the same kernel version.
>
> Obviously, if I use a different kernel the module refuses to load. My first
> guess was to get rid of the module-versioning stuff so that the symbols are
> not mangled, and this seems to work, except that I must use insmod -f module
> for kernels with a different version than what I built with.
MODVERSIONS doesn't mangle the structures/functions it includes a
checksum. If the checksum is the same you are guaranteed the
interface is the same, otherwise something has changed. So
MODVERSIONS is what you want if you want to go between kernels.
> So, if there are guides that I didn't find, or ones on this list that
> someone things I should use, please let me know. Or at least comment on my
> chosen way of doing things. It's this sort of thing that reinforces a
> source form driver is the way to release stuff--then it can be built
> alongside the user's kernel tree...
The general recommendation (I have heard) is to include a bit of
source that provides a kernel abstraction layer that will stay the
same between kernels that your binary only driver can use, and to let
users compile that with different kernels.
But yes. The source form driver is the recommended way to release
kernel code. And I would highly encourage you to figure out how to
do a source release, under the GPL so your driver can be included in
the mainstream kernel. Without that your device will be at best only
semi supported under linux.
Binary only drivers also happen to have another big deficiency that
you haven't mentioned. They don't have a prayer of working on
multiple cpu architectures. And with x86-64 and ia64 just around the
corner this is likely to be a practical issue for a lot of people.
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
"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).
--
bfn,
wabbit
IBM Global Services, UK AMS in Greenock, Scotland.
" To err is human, but to really foul things up requires the root
password. "
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.
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
Christopher Turcksin <[email protected]> writes:
> "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).
It's a good example of the problems, but a bad example of problems
caused be kernel maintenance.
RedHat does not run stock linux kernels, but instead seems to patch
the kernel to include work-around for various known bugs and
deficiencies. What this means is that they are more willing than the
mainstream kernel developers to include changes to the kernel. A
example that comes to mind are the md drivers that implement software
raid.
So for solutions (That I know of):
With recent kernels with modules_install a:
/lib/modules/`uname -r`/build
directory is created, that effectively points to the kernel source
tree the modules were built with. With the 2.4.x currently this is a
symlink so but it should be o.k. It needs to be checked that the
distributors are using this directory appropriately, but it looks like
a good thing to support. Longterm this looks like a solution
to the problem, of how to get kernel headers to match a kernel.
This should even has a chance to work with people who build their own
kernel.
With Redhat and many derivatives as a fallback there is kernel source in
/usr/src/linux that does it's best to match the currently running
kernel.
Using either of those locations for the source to kernel headers it
should be possible to build a package that as part of it's install
process compiles appropriate drivers, at least for most of the cases.
I suspect there is enough work in this for someone to create a support
package, that included makefiles and all the rest to assist in
building a drivers on various platforms. Any takers?
Eric.
> I have the need to distribute a binary-only driver (no flames, please), but
> I am not certain how to build it so that it can be used on multiple kernel
> versions. (Or is this impossible?)
You must build with the same compiler, same tree and options as the
kernel itself.
> I didn't find any "HOWTO (or recommendation) for proper binary-only driver
> release etiquette", so if there are some preferred means, please let me
> know.
The only recomendation is "dont".
> 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
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. "
Eric W. Biederman wrote:
> So for solutions (That I know of):
>
> With recent kernels with modules_install a:
> /lib/modules/`uname -r`/build
> directory is created, that effectively points to the kernel source
> tree the modules were built with. With the 2.4.x currently this is a
> symlink so but it should be o.k. It needs to be checked that the
> distributors are using this directory appropriately, but it looks like
> a good thing to support. Longterm this looks like a solution
> to the problem, of how to get kernel headers to match a kernel.
>
> This should even has a chance to work with people who build their own
> kernel.
>
> With Redhat and many derivatives as a fallback there is kernel source in
> /usr/src/linux that does it's best to match the currently running
> kernel.
>
> Using either of those locations for the source to kernel headers it
> should be possible to build a package that as part of it's install
> process compiles appropriate drivers, at least for most of the cases.
>
> I suspect there is enough work in this for someone to create a support
> package, that included makefiles and all the rest to assist in
> building a drivers on various platforms. Any takers?
I have done exactly this, which I've used for a few device drivers. The
Makefile can usually find the kernel source tree for the running kernel
by looking in the sensible places, it knows where to install modules,
and it is even able to get the right $(CFLAGS) from a configured kernel
tree.
The package includes a "compat.h", which rather like other similar files
("kcompat24.h") provides a 2.4-series API that works with all kernels
going back to 2.0, on all platforms I hope. (I grepped the patches to
find out when each API change that I'm interested in occurred). This
doesn't include network driver API though, just your basic PCI search
and read/write/ioctl/mmap/get_user interfaces.
The nice result is that, from a single source .tar.gz, "make" builds and
installs a driver module written with (more or less) the 2.4 API on any
kernel from 2.0 to 2.4, and the driver source is not full of ifdefs.
I suppose you're wondering where to get these files. Mail me and I'll
see if there's much demand.
cheers,
-- Jamie
Alan Cox <[email protected]> writes:
>> 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.
^free^open source
Ciao
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20