From: Adrian Bunk <bunk@stusta.de>
To: John Richard Moser <nigelenki@comcast.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Driver model.. expel legacy drivers?
Date: Sat, 14 Oct 2006 09:56:25 +0200 [thread overview]
Message-ID: <20061014075625.GA30596@stusta.de> (raw)
In-Reply-To: <4530570B.7030500@comcast.net>
On Fri, Oct 13, 2006 at 11:18:35PM -0400, John Richard Moser wrote:
>
> Here's a silly thought I had a while ago. Linux has no static ABI for
> device drivers, I think the general argument was between "it's slower"
> and "different hardware will have different requirements." Putting
> aside design difficulties, I've come up with an example case of a useful
> hardware driver ABI.
>
> As kernel development goes on, some infrastructure changes require
> drivers to be updated. Eventually some drivers become buggy and
> ill-maintained, even when they used to be legitimately working ones; and
> then developers have to take some of their time to fix them, or eject
> them from the tree.
The rule is simple:
If you break an in-kernel API, you have to fix all in-kernel users.
No matter how ill-maintained a driver is, that works quite good.
>...
> This brings up a few potential questions:
>
> - Will this eventually be necessary to an absolute? Will 100M
> tarballs and hundreds of thousands of drivers be unmanageable in a
> tight, ABI-unstable monolith 10 years from now?
"hundreds of thousands of drivers" won't happen during my lifetime.
If the kernel size only doubles to 100 MB that's no problem.
> - Would it ACTUALLY be worthwhile, given such a scenario, to expel
> drivers out of the tree to glue on by a static, somewhat slower but
> workable ABI so nobody has to touch the code ever?
Documentation/stable_api_nonsense.txt describes why this is nonsense.
And if you anyway don't want to change the kernel API, it doesn't make
any difference for you whether the drives are shipped with the kernel.
And external drivers with various interdependencies and dependencies
would be an insane maintenance nightmare.
> - Is there actually a benefit -now- to ejecting drivers from the tree,
> or are the developers pretty much comfortable polishing the stuff
> nobody normally touches here and there?
The goal is to get drivers into the kernel and shipping a complete
kernel with all drivers.
> Just curious.
This point comes up every few months on this list, so instead of
starting the same old disussion on this topic please read the old
discussions in the list archives.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
next prev parent reply other threads:[~2006-10-14 7:56 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-14 3:18 Driver model.. expel legacy drivers? John Richard Moser
2006-10-14 7:56 ` Adrian Bunk [this message]
2006-10-14 11:19 ` James Courtier-Dutton
2006-10-14 15:04 ` John Richard Moser
2006-10-14 18:54 ` Horst H. von Brand
2006-10-14 20:48 ` John Richard Moser
2006-10-15 15:31 ` Jan Engelhardt
2006-10-14 21:14 ` Kevin K
2006-10-14 21:44 ` John Richard Moser
2006-10-15 0:03 ` Alan Cox
2006-10-14 23:51 ` John Richard Moser
2006-10-15 1:24 ` Kevin K
2006-10-15 1:51 ` Alistair John Strachan
2006-10-15 14:33 ` Alan Cox
2006-10-16 9:39 ` Kasper Sandberg
2006-10-16 14:13 ` Lee Revell
2006-10-16 19:04 ` Lennart Sorensen
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=20061014075625.GA30596@stusta.de \
--to=bunk@stusta.de \
--cc=linux-kernel@vger.kernel.org \
--cc=nigelenki@comcast.net \
/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