All of lore.kernel.org
 help / color / mirror / Atom feed
From: Allan Sandfeld <linux@sneulv.dk>
To: linux-kernel@vger.kernel.org
Subject: Re: 3 Questions
Date: Thu, 29 Nov 2001 09:59:29 +0100	[thread overview]
Message-ID: <E169N2Y-0000zS-00@Princess> (raw)
In-Reply-To: <E169B3r-0005yK-00@the-village.bc.nu>
In-Reply-To: <E169B3r-0005yK-00@the-village.bc.nu>

On Wednesday 28 November 2001 21:12, Alan Cox wrote:
> > 3) Aurora wants to track the driver in its source control system, but
> > they have ISO 900X procedures that require maintaining the build
> > environment under CVS.  The build environment is basically the kernel
> > against which it is developed.  But new developer kernels are released
> > fairly regularly (unlike new versions of Solaris or True64).  Do
> > maintainers of such driver software commonly maintain development
> > environments across a complete range (e.g., all 2.4.* kernels)?  Is
> > there a FAQ with recommendations to help a hardware vendor deal with
> > the nitty gritty details of making sure its driver software works
> > properly across such a range of rapidly changing development
> > environments?
>
> Generally driver vendors only certify/support against "standard" vendor
> released kernels. So instead of Linux they support "SuSE 7.3" "Red Hat 7.2"
> etc..
>
> Most also make a clear distinction between what is submitted to the GPL and
> hacked about under the GPL, and what they will provide any guarantee on.
>
> Think of it like a car.
> 	The engine is only supported for the car it was designed for
> 	You can rebore the engine but you wont get support
> 	You can stick the engine in a different car but you wont get support
>

Unless they release it GPL, then it might be included in the kernel right? 
And "the nitty gritty details of making sure its driver software works
properly across such a range of rapidly changing development
environments" taken care of by the users of the driver.  They can even track 
it by CVS, by requesting all patches against the driver to be submitted to 
them.

They asked for official recommendations, shouldnt the primary recommandation 
not be to open source it, even if some vendors wont?

Regards

  reply	other threads:[~2001-11-29  9:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-28 19:18 3 Questions Joachim Martillo
2001-11-28 20:12 ` Alan Cox
2001-11-29  8:59   ` Allan Sandfeld [this message]
2001-11-29 10:56     ` Alan Cox
  -- strict thread matches above, loose matches on Subject: below --
2002-09-27 23:51 3 questions Shaw, Marco
2002-09-29 21:57 ` Michael Tokarev
2002-09-29 22:23   ` Florent Rougon
2002-09-29 23:15     ` Michael Tokarev
2002-09-30 19:09       ` Florent Rougon
2002-09-29 22:57 Shaw, Marco
2002-09-29 23:19 ` Michael Tokarev

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=E169N2Y-0000zS-00@Princess \
    --to=linux@sneulv.dk \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.