mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Denis Vlasenko <vda@ilport.com.ua>
To: David Chow <davidchow@shaolinmicro.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Linux drivers management
Date: Wed, 8 Feb 2006 10:26:41 +0200	[thread overview]
Message-ID: <200602081026.41487.vda@ilport.com.ua> (raw)
In-Reply-To: <43E8F8EB.8010800@shaolinmicro.com>

On Tuesday 07 February 2006 21:45, David Chow wrote:
> Non-technical Users:
> - Want the system to have drivers pre-built, so that they don't have to 
> go through a compilation or patching process. Its a waste of time for 
> them (waste of time for me too)
> - Why I have to search the drivers? Isn't is suppose to be included in 
> the OS? Or if not included in the OS, it should be included in a driver 
> disk (CD/DVD/floppy or whatever medium or download) .
> - Why I have to upgrade the complete OS if only one driver is missing? I 
> want to stay with Redhat-9 , my PHP runs great.

Then why MS has that auto-update service of theirs?

> - There is no "Linux support" labels on most the hardware out there, 
> should I risk my money, buy it and try out? Oh, full refund of item is 
> not allowed . Then, don't bother ...

Because hardware verdors act stupid and many of them still do
not write open-source drivers (or at least provide adequate docs).

> Commercial developers:
> - Want a stable API so that drivers can be maintained with ease. Because 
> we don't just work with Linux, we want to focus on our driver 
> development, not chasing the API changes, versions by versions, vendors 
> by vendors. Sometimes there are even vendor specific changes, its a 
> waste of time.
> - If I have to make binary drivers, I have to maintain all kernel 
> sources and headers, compilers to make sure my drivers will be built 
> correctly without problem. Of risk to change symbols in the binaries and 
> hope it works!

IOW: "we want to hijack millions of lines of Linux source and won't
contribute back our driver(s). Why do you kernel guys make that hard?"

Because we don't like what you're doing.

> - Where is the latest up-to-date documentation of the kernel API? 
> /Documentation only partially describe what I need, its version 
> specific, sometimes out-of-date, where the hell is that? Let's google it 
> in amazon.com, "Linux driver books", No good again.... Its crap, all not 
> up-to-date!

The source is ultimate doc. You never ever will get such a complete doc
for any commercial OS. It even documents all bugs! ;)

> - Lets get on to it, read all docs and sample sources... mmm... My 
> driver seems working now.. Lets compile it and distribute it. Users: 

Wrong. You should do: "Let's submit it for inclusion in mainline".
If you don't want to, it's your problem, not ours.

> have you got a driver for Redhat 9 2.4.18 kernel? Answer: No, it doesn't 
> work, because I write my driver on 2.6.15, you may to DIY. User 
> response: I want a refund, because you said your hardware has Linux 
> support, but its a false statement.
> - Just leave Linux, who cares, it doens't make sense to us. Because it 
> doesn't make sense to go through all these problems to say "Linux 
> supported hardware", user will get refund the product if we say this on 
> the box on day one.
> - Maybe we have another way to do that, submit the driver to the 
> community and hope it to include it in the latest kernel source. 
> Wait.... but what about support for Redhat 9 and SuSe 8.2?

You may backport your driver to older kernel(s). Sometimes distro(s)
will backport your driver to older kernels if there is demand.

> - We are happy to maintain our own drivers, because we know better about 
> our hardware. We are paid to do so, we also have quality assurance 
> process with formal test tools and equipment. Don't think the community 
> can do a better core than us.

Maintain them "in-tree", not in your own corner.

> - Wake up! Why would the maintainers bother to maintain the drivers if 
> the driver development work is now back to the hardware vendor, like 
> drivers for other platform did? I think someone mis-understood the whole 
> idea is to "GET RID OF DRIVER MAINTENANCE", belive it or not, it belongs 
> to the vendor, not here. If the driver releases as GPL, you can still 
> make your own changes, but it doesn't have to be in main source tree.

Yeah, yeah. I just wrestled with 2 so called "GDI" printers for Windows
from 2 different vendors. Both vendors _refused to fix obvious bugs_
in their Windows drivers. Do you want THIS type of driver maintenance
to occur in Linux world too?
--
vda

  parent reply	other threads:[~2006-02-08  8:27 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-07  4:42 linux
2006-02-07 16:18 ` Eric W. Biederman
2006-02-07 19:45   ` David Chow
2006-02-07 20:03     ` Kyle Moffett
2006-02-07 22:15     ` Theodore Ts'o
2006-02-08  0:52       ` David Chow
2006-02-08  4:02         ` Theodore Ts'o
2006-02-08  9:46         ` Bernd Petrovitsch
2006-02-09  6:09       ` Lee Revell
2006-02-08  1:06     ` Alan Cox
2006-02-08  8:26     ` Denis Vlasenko [this message]
2006-02-11 18:47     ` Andrew James Wade
  -- strict thread matches above, loose matches on Subject: below --
2006-02-06 19:30 Nicolas Mailhot
2006-02-06 18:31 Nicolas Mailhot
2006-02-06 18:56 ` Yaroslav Rastrigin
2006-02-06 19:02 ` Joshua Kugler
2006-02-06 19:17   ` Yaroslav Rastrigin
2006-02-06 19:39     ` Martin Mares
2006-02-06 19:56       ` Jan-Benedict Glaw
2006-02-06 19:53     ` Jan-Benedict Glaw
2006-02-06 20:04     ` Jesper Juhl
2006-02-06 23:52     ` Bernd Petrovitsch
2006-02-06 19:21   ` linux-os (Dick Johnson)
2006-02-06 19:46     ` Michael Krufky
2006-02-06 19:58     ` Nicolas Mailhot
2006-02-06 23:16 ` Gene Heskett
2006-02-06  9:45 David Chow
2006-02-06 10:05 ` Michal Schmidt
2006-02-06 16:50   ` David Chow
2006-02-06 16:55     ` Randy.Dunlap
2006-02-06 19:45     ` Alan Cox
2006-02-06 19:46     ` Jesper Juhl
2006-02-06 10:08 ` Jes Sorensen
2006-02-06 16:52   ` David Chow
2006-02-06 17:03     ` Pedro Alves
2006-02-06 17:35     ` Geert Uytterhoeven
2006-02-06 17:42     ` Jes Sorensen
2006-02-06 16:56 ` Christoph Hellwig
2006-02-07 11:36   ` Denis Vlasenko
2006-02-07 13:22     ` Christoph Hellwig
2006-02-06 19:51 ` Greg KH
2006-02-06 21:38 ` Jim Crilly

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=200602081026.41487.vda@ilport.com.ua \
    --to=vda@ilport.com.ua \
    --cc=davidchow@shaolinmicro.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

Powered by JetHome