linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Richard B. Johnson" <root@chaos.analogic.com>
To: Timothy Miller <miller@techsource.com>
Cc: James Clark <jimwclark@ntlworld.com>,
	Albert Cahalan <albert@users.sourceforge.net>,
	linux-kernel@vger.kernel.org
Subject: Re: Driver Model 2 Proposal - Linux Kernel Performance v Usability
Date: Mon, 15 Sep 2003 07:39:40 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.53.0309150734560.4129@chaos> (raw)
In-Reply-To: <3F6231D7.6040702@techsource.com>

On Fri, 12 Sep 2003, Timothy Miller wrote:

>
>
> Richard B. Johnson wrote:
> > On Wed, 10 Sep 2003, Timothy Miller wrote:
> >
> >
> >>I just have one quick question about all of this:
> >>
> >>People mention that driver interfaces don't change much in stable
> >>releases, but if memory serves, symbol versioning information changes
> >>with each minor release, requiring a recompile of modules.
> >>
> >>Would it be possible to have a driver module which can be dropped into,
> >>say, 2.6.17 that can also be dropped into 2.6.18 as long as the
> >>interface doesn't change?
> >>
> >
> >
> > Short answer, YES. Anything that can be done is possible. The
> > problem is that different kernel versions end up with different
> > structure members, etc. So, you can't use code for 2.2.xxx in
> > 2.4.xx because, amongst other things, the first element in
> > 'struct file_operations' was added and the others moved up.
>
> That's all fine and dandy.  When the kernel changes its interface, then
> you have to recompile (or rewrite) drivers.  No problem.  I'm just
> trying to avoid having to recompile drivers if the interface DOESN'T change.
>
> >
> > Now, you can make a different module interface that maintains
> > a compatibility level ABI. This has been discussed. Unfortunately,
> > this adds code in the execution path. This extra code gets
> > executed every time the module code is accessed. The result being
> > that the module can't possibly operate as fast as it would if
> > there were no such compatibility layer(s). It might be "good enough",
> > but it is unlikely that the module contributors/maintainers would
> > allow such an interface because the loss of performance is measurable
> > and there has been no requirement to trade-off performance for
> > anything (your and my convenience doesn't count, those are not
> > technical issues).
>
> I am not interested in adding additional layers of abstraction.  At
> least not here.  I do it plenty of other places, but that's not
> important right now.  If someone else wants to make an abstraction layer
> (which seems to have been done here and there), then that's just fine,
> and I may or may not use it.
>
> My point is that I'm not advocating any of the kruft associated with
> backward-compatible interfaces.  I'm advocating not having to recompile
> only in the cases where the interface DOES NOT change.
>

In those cases, you simply use "-f" on the `insmod` command line
to force the loading of a module. We have that capability now.
But, the offsets of things your module(s) access can, read will,
be incompatible if the version changed. You "takes you chances and
cross you fingers...." if you use the "-f" option.

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-15 11:38 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1062637356.846.3471.camel@cube>
2003-09-04 20:14 ` Driver Model 2 Proposal - Linux Kernel Performance v Usability James Clark
2003-09-04 20:27   ` Mike Fedyk
2003-09-04 21:16     ` James Clark
2003-09-04 21:50       ` Mike Fedyk
2003-09-04 22:10       ` insecure
2003-09-04 22:01     ` jdow
2003-09-04 20:29   ` Rik van Riel
2003-09-04 21:12     ` James Clark
2003-09-04 21:40       ` Alan Cox
2003-09-04 21:41       ` Bartlomiej Zolnierkiewicz
2003-09-04 22:19       ` Jamie Lokier
2003-09-04 21:29   ` Richard B. Johnson
2003-09-04 21:51     ` James Clark
2003-09-04 22:06       ` Alan Cox
2003-09-04 22:10       ` Martin Mares
2003-09-04 22:23       ` Gustav Petersson
2003-09-05 17:52       ` Valdis.Kletnieks
2003-09-05 18:31         ` James Clark
2003-09-05 18:59           ` Martin Schlemmer
2003-09-05 19:12           ` Dale P. Smith
2003-09-05 19:45             ` Stan Bubrouski
2003-09-05 19:59           ` Richard B. Johnson
2003-09-05 20:01             ` James Clark
2003-09-05 20:08           ` Mike Fedyk
2003-09-05 21:15           ` Valdis.Kletnieks
2003-09-05 23:19             ` Bernd Eckenfels
2003-09-10 20:50     ` Timothy Miller
2003-09-10 20:48       ` Richard B. Johnson
2003-09-10 23:22         ` James Clark
2003-09-10 23:58           ` Greg KH
2003-09-12 20:51         ` Timothy Miller
2003-09-12 20:55           ` Tim Hockin
2003-09-15 11:39           ` Richard B. Johnson [this message]
2003-09-05 20:53 Chad Kitching
2003-09-05 23:30 ` Mike Fedyk
  -- strict thread matches above, loose matches on Subject: below --
2003-09-04 22:41 Chad Kitching
2003-09-03 17:53 James Clark
2003-09-03 17:49 ` Andre Hedrick
2003-09-03 18:23   ` Guillaume Morin
2003-09-04  4:10     ` Andre Hedrick
2003-09-03 18:35   ` Guillaume Morin
2003-09-03 19:30     ` Andre Hedrick
2003-09-03 18:18 ` Greg KH
2003-09-03 18:23 ` Richard B. Johnson
2003-09-03 18:49 ` Patrick Mochel
2003-09-03 18:58 ` Gábor Lénárt
2003-09-03 20:18 ` Christoph Hellwig

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.0309150734560.4129@chaos \
    --to=root@chaos.analogic.com \
    --cc=albert@users.sourceforge.net \
    --cc=jimwclark@ntlworld.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miller@techsource.com \
    /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).