linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Richard B. Johnson" <root@chaos.analogic.com>
To: James Clark <jimwclark@ntlworld.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Driver Model
Date: Tue, 2 Sep 2003 16:44:50 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.53.0309021620050.4709@chaos> (raw)
In-Reply-To: <200309021943.15875.jimwclark@ntlworld.com>

On Tue, 2 Sep 2003, James Clark wrote:

> 1. Will the move to a more uniform driver model in 2.6 increase the
> chances of
> a given binary driver working with a 2.6+ kernel.
>

Most changes to the kernel are made without any consideration
of a so-called binary drivers at all. FWIW all drivers are "binary".
If a file is created that was generated for a specific kernel version,
it will work on that kernel version whether or not the driver
sources are available. If the driver does not contain the appropriate
MODULE_LICENSE() string, then several tools will show "tainted" so
that kernel developers will not waste time attempting to find a problem
with a kernel that might be caused by a driver. If the driver has its
source-code released, shown by the appropriate MODULE_LICENSE() string,
then kernel developers may review that driver and fix it if it
is causing a kernel problem.

> 2. Will the new model reduce the use/need for kernel modules. Would this be a
> good thing if functionality could be implemented in a driver instead of a
> module.
>

The current trend is to make all drivers modules. That way, the
kernel will not be bloated with thousands of drivers that are never
used. Basically, the kernel will have just enough hardware-interface
to boot, possibly into a RAM Disk. Then the modules necessary to
support the specific hardware are loaded, the devices initialized
and the boot continues.

> 3. Will the practice of deliberately breaking some binary only 'tainted'
> modules prevent take up of Linux. Isn't this taking things too far?
>
> James
> -

There is no such practice going on at this time. A module must
be compiled using the same interface elements (structure members, etc.)
as the kernel. Therefore it must have the same version number, compiled
against the same kernel headers. If the designer of the module can't
make the source code public (usually because of corporate restrictions)
then, if there is a problem that you need to report to the kernel
development group, you need to make sure that the "secret" module
is not installed at that time.  If the secret module is causing
the kernel problem, which is seldom the case BYW, then you need to
contact the provider of the secret module. They may have a brand-
new version that works perfectly.

A case-in-point: A truly MAJOR screen-card developer has not been
allowed to make the source-code publically available because of
corporate restrictions (A publically-owned company might not be
able to make their intellectual property public. This might cause
a stock-holder revolt). This major company has quickly responded
to failures of their modules to work in the latest kernel versions.
The result is that they have a good working relationship, even though
inserting one of their drivers will cause the OPPS reporting software
to declare that the kernel is "tainted".

You don't get a "tainted" message otherwise. You just get good
screen graphics.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (794.73 BogoMips).
            Note 96.31% of all statistics are fiction.



  parent reply	other threads:[~2003-09-02 20:44 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-02 18:43 Driver Model James Clark
2003-09-02 19:13 ` Robert Love
2003-09-02 20:44 ` Richard B. Johnson [this message]
2003-09-03 14:36   ` Stuart MacDonald
2003-09-03 14:52     ` Jan-Benedict Glaw
2003-09-03 14:57     ` Alan Cox
2003-09-03 15:13       ` Stuart MacDonald
2003-09-03 15:33         ` Mariusz Zielinski
2003-09-03 15:50           ` Stuart MacDonald
2003-09-03 16:02             ` Mariusz Zielinski
2003-09-03 17:58               ` Stuart MacDonald
2003-09-03 16:58             ` Alan Cox
2003-09-03 18:21               ` Jeff Garzik
2003-09-03 15:50           ` Mariusz Zielinski
2003-09-03 22:41       ` David Schwartz
2003-09-04 11:03         ` Alan Cox
2003-09-03 15:22     ` Richard B. Johnson
2003-09-02 21:29 ` Patrick Mochel
2003-09-02 21:44   ` James Clark
2003-09-02 22:05     ` Greg KH
2003-09-02 22:08     ` Robert Love
2003-09-02 22:39     ` Jamie Lokier
2003-09-02 23:52 ` Andre Hedrick
2003-09-03  0:20   ` David Schwartz
2003-09-03 17:38     ` Andre Hedrick
2003-09-03 18:19       ` Alan Cox
2003-09-03 18:15         ` Andre Hedrick
2003-09-04 12:40       ` Henning P. Schmiedehausen
2003-09-03 13:10 ` Alan Cox
     [not found] <rtHg.3n0.9@gated-at.bofh.it>
     [not found] ` <rK5y.1xN.25@gated-at.bofh.it>
2003-09-03 18:42   ` Pascal Schmidt
2003-09-03 19:49     ` Andre Hedrick
2003-09-03 22:41     ` David Schwartz
2003-09-03 23:11       ` Pascal Schmidt
2003-09-03 23:33         ` David Schwartz
2003-09-04  1:38           ` Pascal Schmidt
2003-09-04  3:01             ` David Schwartz
2003-09-04 14:21               ` Pascal Schmidt
2003-09-04  1:37         ` Andre Hedrick

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.53.0309021620050.4709@chaos \
    --to=root@chaos.analogic.com \
    --cc=jimwclark@ntlworld.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).