Build a device driver on another machine - Slackware

This is a discussion on Build a device driver on another machine - Slackware ; Hi, I wonder if I can normally build a device driver on a machine for another machine. Say I have a series of Slackbuild scripts for wireless devices like rt61, rt2500, ipw2200, ipw3945... can I build packages for these on ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Build a device driver on another machine

  1. Build a device driver on another machine

    Hi,

    I wonder if I can normally build a device driver on a machine for another
    machine. Say I have a series of Slackbuild scripts for wireless devices
    like rt61, rt2500, ipw2200, ipw3945... can I build packages for these on
    one (central) machine that doesn't necessarily have any of these devices?

    cheers,

    Niki

  2. Re: Build a device driver on another machine

    On 2007-10-30, Niki Kovacs wrote:
    >
    > I wonder if I can normally build a device driver on a machine for another
    > machine. Say I have a series of Slackbuild scripts for wireless devices
    > like rt61, rt2500, ipw2200, ipw3945... can I build packages for these on
    > one (central) machine that doesn't necessarily have any of these devices?



    Yes, in fact, a virtual machine is a great place to do this.
    For the ones that build kernel modules, be aware that the kernel
    files on the development box need to be identical to those on the
    production boxes. In essence, if you're running the stock generic
    Slackware kernel on the production boxes, then using the stock
    generic kernel on the build box will produce good working packages
    without any problem at all.

    -RW

  3. Re: Build a device driver on another machine

    Le Tue, 30 Oct 2007 18:18:18 +0000, Robby Workman a √©crit¬*:

    > On 2007-10-30, Niki Kovacs wrote:
    >>
    >> I wonder if I can normally build a device driver on a machine for
    >> another machine. Say I have a series of Slackbuild scripts for wireless
    >> devices like rt61, rt2500, ipw2200, ipw3945... can I build packages for
    >> these on one (central) machine that doesn't necessarily have any of
    >> these devices?

    >
    >
    > Yes, in fact, a virtual machine is a great place to do this. For the
    > ones that build kernel modules, be aware that the kernel files on the
    > development box need to be identical to those on the production boxes.


    Which is the case, so that should be no problem.

    > In essence, if you're running the stock generic Slackware kernel on the
    > production boxes, then using the stock generic kernel on the build box
    > will produce good working packages without any problem at all.


    OK. Thanks very much!

    Niki


  4. Re: Build a device driver on another machine

    > Yes, in fact, a virtual machine is a great place to do this.
    > For the ones that build kernel modules, be aware that the kernel
    > files on the development box need to be identical to those on the
    > production boxes.


    Also the compiler needs to be the same.
    In case OP tries to compile drivers on a older or newer distro.


    --
    damjan

  5. Re: Build a device driver on another machine

    Damjan wrote:

    > Also the compiler needs to be the same.


    I think it's the (dynamically loaded) libraries that matter, not the
    compiler.

    --
    ----------------------------------------------------------------------
    Sylvain Robitaille syl@alcor.concordia.ca

    Systems and Network analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

  6. Re: Build a device driver on another machine

    >> Also the compiler needs to be the same.
    >
    > I think it's the (dynamically loaded) libraries that matter, not the
    > compiler.


    libraries?
    We are talking about kernel modules (aka drivers).

    As can be seen here http://tldp.org/LDP/lkmpg/2.6/html/lkmpg.html
    the gcc version is part of the "vermagic" of a module.


    Hmm.. although now when I do a "modinfo ehci-hcd" I only get
    "2.6.23-dg SMP mod_unload PENTIUMM" ... maybe the GCC restriction was lifted
    recently??? but I doubt that.




    --
    damjan

  7. Re: Build a device driver on another machine

    Damjan wrote:

    > libraries?
    > We are talking about kernel modules (aka drivers).


    Point taken. I overlooked that.

    > As can be seen here http://tldp.org/LDP/lkmpg/2.6/html/lkmpg.html
    > the gcc version is part of the "vermagic" of a module.


    That would imply, however, that a hardware vendor wishing to provide a
    pre-compiled binary-only driver for one of their devices would need to
    provide a different one for nearly all the different Linux distributions
    out there (or at least one for each of the main ones, compiled with that
    distribution's compiler).

    I only have one system at the moment with a module-capable kernel (a
    laptop running Slackware-12.0, for which I need the ipw2200 module,
    and it wants to be dynamically loaded for some reason), and I don't see
    the GCC version in that module's "vermagic" string (similar to what you
    found for your ehci-hcd module).

    > Hmm.. although now when I do a "modinfo ehci-hcd" I only get
    > "2.6.23-dg SMP mod_unload PENTIUMM" ... maybe the GCC restriction was
    > lifted recently??? but I doubt that.


    Hrmmm... a quick search through the documentation in the source tree
    for 2.6.23.1 doesn't provide any insight either way ....

    --
    ----------------------------------------------------------------------
    Sylvain Robitaille syl@alcor.concordia.ca

    Systems and Network analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

  8. Re: Build a device driver on another machine

    >> Hmm.. although now when I do a "modinfo ehci-hcd" I only get
    >> "2.6.23-dg SMP mod_unload PENTIUMM" ... maybe the GCC restriction was
    >> lifted recently??? but I doubt that.

    >
    > Hrmmm... a quick search through the documentation in the source tree
    > for 2.6.23.1 doesn't provide any insight either way ....


    Well, at least on 2.6.18 system (a Debian 4.0) and 2.6.15 (some older Slack
    boxes) the GCC version is part of the vermagic.

    --
    damjan

  9. Re: Build a device driver on another machine

    Damjan wrote:

    > Well, at least on 2.6.18 system (a Debian 4.0) and 2.6.15 (some older
    > Slack boxes) the GCC version is part of the vermagic.


    Ah yes ... linux-2.6.15.6/include/linux/vermagic.h contains:

    #define VERMAGIC_STRING \
    UTS_RELEASE " " \
    MODULE_VERMAGIC_SMP MODULE_VERMAGIC_PREEMPT \
    MODULE_ARCH_VERMAGIC \
    "gcc-" __stringify(__GNUC__) "." __stringify(__GNUC_MINOR__)

    and linux-2.6.19.2/include/linux/vermagic.h has instead:

    #define VERMAGIC_STRING \
    UTS_RELEASE " " \
    MODULE_VERMAGIC_SMP MODULE_VERMAGIC_PREEMPT \
    MODULE_VERMAGIC_MODULE_UNLOAD MODULE_ARCH_VERMAGIC

    So it does seem to change at linux-2.6.19 ...
    (I don't have any sources already unpacked between those versions, but
    the above is probably sufficient to confirm what's being seen ...)

    --
    ----------------------------------------------------------------------
    Sylvain Robitaille syl@alcor.concordia.ca

    Systems and Network analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

  10. Re: Build a device driver on another machine

    > So it does seem to change at linux-2.6.19 ...
    > (I don't have any sources already unpacked between those versions, but
    > the above is probably sufficient to confirm what's being seen ...)


    Here it is, it's the last change in vermagic.h, done on 2006-09-26
    http://tinyurl.com/2rge4q

    From the comment of the diff, this happened since they dropped gcc-2.95
    support from the kernel.


    --
    damjan

+ Reply to Thread