public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Chow <davidchow@shaolinmicro.com>
To: Jes Sorensen <jes@sgi.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Linux drivers management
Date: Tue, 07 Feb 2006 00:52:58 +0800	[thread overview]
Message-ID: <43E77EEA.7040908@shaolinmicro.com> (raw)
In-Reply-To: <yq0d5i0ol4i.fsf@jaguar.mkp.net>


>David> separate Linux drivers and the the main kernel, and manage
>David> drivers using a package management system that only manages
>David> kernel drivers and modules? If this can be done, the kernel
>David> maintenance can be simple, and will end-up with a more stable
>David> (less frequent changed) kernel API for drivers, also make every
>David> developers of drivers happy.
>
>David> Would like to see that happens .
>
>Simple answer: no
>
>Maybe someone is working on it, but it's highly unlikely to be
>anything but a waste of that person's time.
>
>This is a classic question, by seperating out the drivers you make it
>so much harder for all developers to propagate changes into all pieces
>of the tree.
I write drivers, never need to change kernel if the kernel API is mature 
enough to provide the need of a module developer needs. There is no 
reason to make changes to the kernel source, only needed because the 
original kernel code is crap or the API designed without proper 
software/system architectural design work effort. Each Linux kernel 
version go through a lengthy beta release cycle (e.g. 2.3, 2.5, 2.7), 
this shouldn't happen and idea collection should be enough through this 
large Linux community.

If our time is to focus on kernel's kernel, writing good documentation 
about a stable kernel API, it will benefit many developers to write 
drivers to Linux . It is too difficult to learn, this is a main reason 
why Linux is lack of support from manufacturer drivers, not because they 
don't like Linux and no market, it is because this has created high 
entry barrier for them.

I've been working on Linux modules for many years, training my 
engineers, talking to developers, hw manufacturers .. believe it or not, 
this is the main reason. They all ask for a DDK for Linux that can make 
drivers easily for their product.

I think I am in a different position like you guys, I've been work with 
Linux from programmer level to Linux promotion . My goal is not just 
focus on Linux technical or programming, I would like to promote this 
operating system to not just for programmers, but also non-technical 
end-users . Writing C code to me is just bits of task of some process.  
You are too much focus on programming without considering the market 
situation.

There is no right or wrong for this question, but my original question 
is to listen thoughts and to hear the goal of people in the list. And of 
course, I would really like to see you people look into the way to 
facilitate more people gets a path with ease to Linux drivers 
development. User driver installation without the need to know about 
kernel sources, gcc, make etc....  "Because I am a dummy, I want to 
plug-in my device, put in the driver disc and hope it works!"

regards,
David Chow

  reply	other threads:[~2006-02-06 16:53 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-06  9:45 Linux drivers management 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 [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
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 19:30 Nicolas Mailhot
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
2006-02-11 18:47     ` Andrew James Wade

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=43E77EEA.7040908@shaolinmicro.com \
    --to=davidchow@shaolinmicro.com \
    --cc=jes@sgi.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