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
next prev parent 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