public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Christopher Turcksin <turcksin@raleigh.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Miller, Brendan" <Brendan.Miller@Dialogic.com>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Proper way to release binary driver?
Date: Fri, 06 Apr 2001 16:50:29 +0100	[thread overview]
Message-ID: <3ACDE5C5.CEB65D4A@raleigh.ibm.com> (raw)
In-Reply-To: <EFC879D09684D211B9C20060972035B1D46A39@exchange2ca.sv.dialogic.com> <m1g0fnwoo0.fsf@frodo.biederman.org>

"Eric W. Biederman" wrote:

> 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
> issue.

Eric,

I am finding myself exactly in this situation, and I've got a feeling
that this won't be the last time either.

I expect that every future Linux driver I get involved with will be
released under GPL. However, I think that the majority of our customers
will be running a distribution that does not yet support a new driver,
and even at Linux speeds, it'll take a long enough time that customers
cannot afford to wait for the next release that includes the driver.

So the big issue for us appears to be how we support these customers.

There is no way that we can support customers who have custom kernels,
but since they are 'in it' enough to compile their own kernel, I guess
they're able to apply our patch and recompile it. I actually suspect
that there aren't that many who do this anyway.

Where we find we have a problem is the number of different 'standard'
kernels out there. We find that we need to support all releases since
the last year or so for each distribution. And for each of those, we
find that there are many different kernel versions (some bugfixes, some
provide half a dozen different kernels with the CDs, aso.). And since we
do not expect these customers to compile their own kernel, we see no
option but to provide a precompiled binary driver. The numbers multiply
quickly and building all of those becomes an interesting problem.

We had hoped that MODVERSIONS would allow us to provide a single (or at
most a few) binary driver. Kernels with even minor version numbers are
supposed to be stable (even if they are buggy) ie. not have wildly
changing kernel interfaces.

In practice, that doesn't work. A driver compiled with 2.2.16 doesn't
load with 2.2.16-5.0 (from RedHat 6.2) (just an example). 



-- 
bfn,
wabbit

IBM Global Services, UK AMS in Greenock, Scotland.

	" To err is human, but to really foul things up requires the root
password. "

  reply	other threads:[~2001-04-06 15:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-05 10:58 Proper way to release binary-only driver? Miller, Brendan
2001-04-05 11:50 ` Eric W. Biederman
2001-04-06 15:50   ` Christopher Turcksin [this message]
2001-04-06 16:09     ` Proper way to release binary driver? Joel Jaeggli
2001-04-06 16:22     ` J . A . Magallon
2001-04-07  1:24     ` How to build modules outside the kernel tree? [Was: Proper way to release binary driver?] Eric W. Biederman
2001-04-08 13:10       ` Jamie Lokier
2001-04-07  8:18     ` Proper way to release binary driver? Alan Cox
2001-04-09 13:11       ` Henning P. Schmiedehausen
2001-04-07 11:06     ` Christopher Turcksin
2001-04-06  5:33 ` Proper way to release binary-only driver? Alan Cox

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=3ACDE5C5.CEB65D4A@raleigh.ibm.com \
    --to=turcksin@raleigh.ibm.com \
    --cc=Brendan.Miller@Dialogic.com \
    --cc=ebiederm@xmission.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