[lkml]   [2001]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Proper way to release binary-only driver?
    "Miller, Brendan" <> 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

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:24    [W:0.023 / U:14.904 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site