How can I make device driver module to support many version of kernel?

How can I make device driver module to support many version of kernel?

Post by ±è?ü? » Tue, 24 Aug 1999 04:00:00



I compiled one device driver in kernel 2.2.9.  And copy it to other
system,

try to insert module in kernel with insmod command. But  I can't because

other system has kernel 2.2.5.  But that device driver source can be
compile

and run in kernel 2.2.5. How can I make device driver module to support

every kernel version 2.2.X?

 
 
 

How can I make device driver module to support many version of kernel?

Post by Peter Samuels » Tue, 24 Aug 1999 04:00:00



Quote:> I compiled one device driver in kernel 2.2.9.  And copy it to other
> system, try to insert module in kernel with insmod command. But I
> can't because other system has kernel 2.2.5.  But that device driver
> source can be compile and run in kernel 2.2.5. How can I make device
> driver module to support every kernel version 2.2.X?

You can't.  You can enable MODVERSIONS support (one of the `make
config' questions) but it will not *always* work, only sometimes.
2.2.11 is not very binary-compatible with 2.2.10, for example.

Why can't you do this, when drivers in 'doze, AIX and other Unices work
fine across versions?  Because the layering necessary is not good for
either code maintainability or performance, and there is no felt need
for it.  The only people seriously inconvenienced are those who would
distribute closed-source drivers.

--
Peter Samuelson
<sampo.creighton.edu!psamuels>

 
 
 

How can I make device driver module to support many version of kernel?

Post by Eric Hegstro » Tue, 24 Aug 1999 04:00:00



> The only people seriously inconvenienced are those who would
> distribute closed-source drivers.

Well it can be pain even if you have the source code really.

--
Eric Hegstrom                          .~.
Senior Software Engineer               /V\  
Sonoran Scanners, Inc.                // \\          L I N U X

520-617-0072 x402                     ^^-^^

 
 
 

How can I make device driver module to support many version of kernel?

Post by Tim Hal » Wed, 25 Aug 1999 04:00:00




> > The only people seriously inconvenienced are those who would
> > distribute closed-source drivers.

> Well it can be pain even if you have the source code really.

> --
> Eric Hegstrom                          .~.
> Senior Software Engineer               /V\
> Sonoran Scanners, Inc.                // \\          L I N U X

> 520-617-0072 x402                     ^^-^^

An excellent point..
I just started on a project to develop PCI and ISA drivers for a variety
of computer telephony DSP cards. There have been substantial changes in
the PCI access functions since 2.0. Therefore, we had to make a decision
whether to have a lot of conditional compilation code or limit our driver
to support a given set of kernel releases.
The rapid ongoing of Linux is a mixed blessing. Great for people who need
support for more and more devices, a pain for those folks actually
providing the driver code.
Yes, I know a lot of Linux developers will take exception to this, but
this 'feature' could cause longterm problems in having hardware
developers providing Linux support for their boards.

Tim Hall
Senior Software Engineer
Natural MicroSystems

 
 
 

How can I make device driver module to support many version of kernel?

Post by Peter Samuels » Wed, 25 Aug 1999 04:00:00



Quote:> I just started on a project to develop PCI and ISA drivers for a
> variety of computer telephony DSP cards. There have been substantial
> changes in the PCI access functions since 2.0. Therefore, we had to
> make a decision whether to have a lot of conditional compilation code
> or limit our driver to support a given set of kernel releases.

There are always tradeoffs.  The obvious alternatives:

* Not develop as fast.  Sorry....

* Develop as now but never make incompatible changes.  Unfortunately
  everyone's hands are forever tied by bad design decisions, and no old
  stuff can ever get "cleaned up".  This is a problem the Microsoft OS
  groups are always having to face and nobody envies them for it.

* Define a "compatibility layer" either now or whenever something
  changes, which is more or less guaranteed *not* to change.  This is
  what libc provides (so that, for example, if the pre-2.2 version of
  the `umount' system call is ever dropped, programs that use it will
  still run fine so long as a semi-recent libc is installed).  The idea
  here is that the libc layer would have a kernel-mode equivalent.
  Linus is adamantly opposed to this, though.  He believes that such a
  layer is needlessly inefficient, complex at the source level, and
  still ends up tying your hands.

Quote:> The rapid ongoing of Linux is a mixed blessing. Great for people who
> need support for more and more devices, a pain for those folks
> actually providing the driver code.

Unless you're someone like Cyclades, who contributes their own drivers
to the stock kernel tree where they tend to get updated whenever major
interface changes come down the pipe.  And then, although they provide
most of the driver updates, at least they don't have to worry about
providing their customers with the "correct" version of the driver --
it's in the "correct" source tree already.

Quote:> Yes, I know a lot of Linux developers will take exception to this,
> but this 'feature' could cause longterm problems in having hardware
> developers providing Linux support for their boards.

Note that the issue at hand was not source-level compatibility (like
the PCI BIOS stuff you mentioned) but binary compatibility.
Source-level compatibility is actually quite good within a given stable
release cycle (like 2.0.* or 2.2.*).  However, *binary* compatibility
is not, so if you're reticent about giving out your driver source, you
have to compile for individual releases and SMP/non-SMP.  The AFS
people complain about this occasionally.

--
Peter Samuelson
<sampo.creighton.edu!psamuels>

 
 
 

How can I make device driver module to support many version of kernel?

Post by Eric Hegstro » Wed, 25 Aug 1999 04:00:00


Within a release cycle yes. Across a release cycle (lets say 2.0.x to
2.1.x) there are some very non-trivial changes. I think this is the
concern that Tim was refering to. I think concerns with longterm
migration are very valid. I have had to make the tradeoff myself.

-Eric


> Source-level compatibility is actually quite good within a given stable

                                                    ^^^^^^

Quote:> release cycle (like 2.0.* or 2.2.*).  However, *binary* compatibility
> is not, so if you're reticent about giving out your driver source, you
> have to compile for individual releases and SMP/non-SMP.  The AFS
> people complain about this occasionally.

--
Eric Hegstrom                          .~.
Senior Software Engineer               /V\  
Sonoran Scanners, Inc.                // \\          L I N U X

520-617-0072 x402                     ^^-^^
 
 
 

How can I make device driver module to support many version of kernel?

Post by Marcus Sundber » Wed, 25 Aug 1999 04:00:00



> * Define a "compatibility layer" either now or whenever something
>   changes, which is more or less guaranteed *not* to change.  This is
>   what libc provides (so that, for example, if the pre-2.2 version of
>   the `umount' system call is ever dropped, programs that use it will
>   still run fine so long as a semi-recent libc is installed).  The idea
>   here is that the libc layer would have a kernel-mode equivalent.
>   Linus is adamantly opposed to this, though.  He believes that such a
>   layer is needlessly inefficient, complex at the source level, and
>   still ends up tying your hands.

Linus doesn't have to like it.
People/companies wanting to provide binary only modules can write
their own (Open Source) compability layer and distribute it with
their binary drivers. Seems to work just fine for Vmware.

Quote:> so if you're reticent about giving out your driver source, you
> have to compile for individual releases and SMP/non-SMP.  The AFS
> people complain about this occasionally.

Let them complain then. ;-)
http://www.stacken.kth.se/projekt/arla/

//Marcus
--
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404

 
 
 

How can I make device driver module to support many version of kernel?

Post by Nix » Sat, 28 Aug 1999 04:00:00



> People/companies wanting to provide binary only modules can write
> their own (Open Source) compability layer and distribute it with
> their binary drivers. Seems to work just fine for Vmware.

And for coda, although in their case it's not binary-only that's the
problem but a fscking massive client. 10Mb for a module's data space
would *not* be good ;)

--
'- I can't believe my room doesn't have Ethernet!  Why wasn't it wired
   when the house was built?
 - The house was built in 1576.' --- Alex Kamilewicz on the Cambridge
                                     breed of `conference American'.

 
 
 

1. Ft. Worth - Linux Kernel Module Programmer - Unix kernel modules & Unix device drivers

Linux Kernel Module Programmer - A very loose environment, casual attire,
needs an intermediate to advanced Linux Kernel Module Programmer
immediately for a critical role. This person must have specific experience
in programming Unix kernel modules or drivers and TCP/sockets, preferably
with Linux kernel modules or drivers, or an understanding or experience of
parallel and distributed processing. Program a Linux kernal module to
fulfill the need for a routing program performing communications and shared
server resource management on web servers. These programming tasks are below
the socket level, but some manipulation of sockets is part of the tasks.
This person will perform cutting edge server applications development in a
parallel and distributed environment. This experience is a huge resume
boost.

Required Skills: MUST HAVE experience in programming a Unix or Linux KERNAL
MODULE or DRIVER! ... and C / Unix, networks and protocols, an innovative
mind that enjoys thinking out of the box, good work ethic, work well alone,
self motivated, requires little supervision.

Desired Skills: parallel and distributed processing.

Start Date: ASAP

Type: - Permanent -

Pay Range: $60,000 - $65,000 Annual
+stock options

Benefits: Health Insurance, Life Insurance, Dental Insurance, Disability
Insurance, Paid Vacation, Paid Sick Leave, Stock Options, Flex Time

Location: Ft. Worth , TX - Hurst, TX
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TO APPLY, PLEASE CALL OR FORWARD RESUME TO:

Larry Bergstrom
Computer Staff, LLC
1701 W. Northwest Highway
Grapevine, Texas 76051-8105

OFFICE metro  (817) 329-5009
FAX   (817) 329-5091
WEBSITE:  http://www.compstaffonline.com/listings.html
HOME  (817) 251-2029
MOBILE  (817) 723-4298
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Information Technology Contract & Permanent Placement Services
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ALL RESUME RESPONDENTS ARE HELD CONFIDENTIAL
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2. Alpha & LINUX SCSI questions. Urgent answers needed.

3. Module Programming: module version vs. kernel version

4. No sound from cd-rom

5. Kernel module version support.

6. ATI Mach 64 Help Needed

7. Compiling kernel with module version support disabled

8. what to do with "too much" RAM?

9. Device driver changes for new Kernel versions...

10. Can I compile device driver which is independent on kernel version?

11. when the new kernel version updated what should be chnaged in device driver code?

12. Kernel 2.2 and device driver/modules

13. beginner module question: kernel-module version mismatch