public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John Richard Moser <nigelenki@comcast.net>
To: linux-kernel@vger.kernel.org
Subject: Driver model.. expel legacy drivers?
Date: Fri, 13 Oct 2006 23:18:35 -0400	[thread overview]
Message-ID: <4530570B.7030500@comcast.net> (raw)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

  (I can't think of any specific cases where a driver has actually
become buggy enough that it became a notable hazard.  OSS eventually was
deprecated and pulled out of the tree because its architecture was old
and it wasn't worth keeping since we have ALSA now.)

The drivers have to be shipped in the main tree as well, and the kernel
tarballs are getting bigger.  2.6.14 was in a 37M .tar.bz2; .15 was in a
38M; .16 and .17 in a 39M; .18 is in a 40M tarball.  The size keeps
piling up, that's more and more code that's got to be maintained and
shipped.

Writing Linux into a microkernel isn't going to happen.  Linus isn't hot
on the idea; and besides, what would the developers DO with that kind of
disruption?  Tons of projects would drop off because basement coders
can't all rewrite their code for a new architecture (hey why not port
your new Linux memory management patch to FreeBSD while you're at it?).
 So the only other way to isolate parts of the kernel off the main tree
is, obviously, by making a way to move drivers out of it.

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?

  - 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?

  - 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?

Just curious.


- --
    We will enslave their women, eat their children and rape their
    cattle!
                  -- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBRTBXCQs1xW0HCTEFAQKQyA/+Psr/NMmyrGGKBxeRw4AchHS2danZlS87
Mps20R8tm9CJMWUuPw0xZneBWz5kzG9MPJ4HvcAB4BZK1mp7a/ojFePIu1ZMW2qr
Xqn+yqk4vBr3ayh0Z8OFicxdDoJ/i47ON1h3QYfi3X9N/aLG/nMgFVbXJZ6CnImt
HQqj2YHGhvzu2CEQqYh3BzVOZkBJJ7AMgmIVUzajIrbGtR2/0XTyLvGfPYr9hzi0
N1YS+Rrgo7UoHU54qOjXoFWrrmvRc27vZydPTyU7DPDnruNNljS9QnfuT1XQbzyq
wM1+nFr6gHKPHI3MiZ3IktQnDSy0FQV08TRrTkFq88kE5zT79NkZIH7L4rQtN/VN
+dUV1JIQ1FvEnCATUpYueyb01BOIFK1xMIS2UMOFaghF09GmWhd+eIk80TT8PVaK
PvjEJ8FqQjSBqBPKzHVD8e1q86pfjZmLrQH+djLkkmfGXnqKG3BUWBfX+h4pQii5
iEpo0eznfxCvejvnyrWgl2jsKYW0dff7R4MQoPP99MgHXK7/hV4jmJTjNsh5z13j
vy+na5HR99IsGzBfwDgJIu6UPxq0Zf6JlP33dzeFgYyc3zAlAJMrrAZYDe+3xJsA
LJ7kNAdv51UhPQwAW45q+fWsn4iVOe9RgyNL5fBl4D8TkYdaHdsx2UVEoY54QEAZ
1O4ALzjdnVY=
=owQK
-----END PGP SIGNATURE-----

             reply	other threads:[~2006-10-14  3:18 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-14  3:18 John Richard Moser [this message]
2006-10-14  7:56 ` Driver model.. expel legacy drivers? Adrian Bunk
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=4530570B.7030500@comcast.net \
    --to=nigelenki@comcast.net \
    --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