public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: James Clark <jimwclark@ntlworld.com>
To: linux-kernel@vger.kernel.org
Cc: rml@tech9.net, root@chaos.analogic.com, mochel@osdl.org,
	alan@lxorguk.ukuu.org.uk
Subject: Driver Model 2 Proposal - Linux Kernel Performance v Usability
Date: Wed, 3 Sep 2003 18:53:01 +0100	[thread overview]
Message-ID: <200309031850.14925.jimwclark@ntlworld.com> (raw)

Following my initial post yesterday please find attached my proposal for a 
binary 'plugin' interface:

This is not an attempt to have a Microkernel, or any move away from GNU/OSS 
software. I believe that sometimes the ultimate goals of stability and 
portability get lost in the debate on OSS and desire to allow anyone to 
contribute. It is worth remembering that for every Kernel hacker there must 
be 1000's of plain users. I believe this proposal would lead to better 
software and more people using it.

Proposal
-----------
1. Implement binary kernel 'plugin' interface
2. Over time remove most existing kernel 'drivers' to use new interface - This 
is NOT a Microkernel.
3. Design 'plugin' interface to be extensible as possible and then rarely 
remove support from interface. Extending interface is fine but should be done 
in a considered way to avoid interface bloat. Suggest interface supports 
dependant 'plugins'
4. Allow 'plugins' to be bypassed at boot - perhaps a minimal 'known good' 
list
5. Ultimately, even FS 'plugins' could be created although IPL would be 
required to load these. 
6. Code for Kernel, Interface and 'plugins' would still be GPL. This would not 
prevent the 'tainted' system idea. 

Expected Outcomes
------------------------

1. Make Linux easier to use
2. The ability to replace even very core Kernel components without a restart.
3. Allow faulty 'plugins' to be fixed/replaced in isolation. No other system 
impact.
4. 'Plugins' could create their own interfaces as load time. This would remove 
the need to pre-populate /dev. 
5. Remove need for joe soap user to often recompile Kernel.
6. Remove link between specific module versions and Kernel versions.
7. Reduce need for major Kernel releases. Allow effort to concentrate on 
improving Kernel not maintaining ever increasing Kernel source that includes 
support for the 'Kitchen Sink'
8. Make core Kernel more stable. Less releases and less changes mean less 
bugs. It would be easy to identify offending 'plugin' by simply starting up 
the Kernel with it disabled.
9. Remove need for modules to be maintained in sync with each Kernel thus 
freeing 'module' developers to add improved features or work on new projects.

James



             reply	other threads:[~2003-09-03 17:53 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-03 17:53 James Clark [this message]
2003-09-03 17:49 ` Driver Model 2 Proposal - Linux Kernel Performance v Usability Andre Hedrick
2003-09-03 18:23   ` Guillaume Morin
2003-09-04  4:10     ` Andre Hedrick
2003-09-03 18:35   ` Guillaume Morin
2003-09-03 19:30     ` Andre Hedrick
2003-09-03 18:18 ` Greg KH
2003-09-03 18:23 ` Richard B. Johnson
2003-09-03 18:49 ` Patrick Mochel
2003-09-03 18:58 ` Gábor Lénárt
2003-09-03 20:18 ` Christoph Hellwig
     [not found] <1062637356.846.3471.camel@cube>
2003-09-04 20:14 ` James Clark
2003-09-04 20:27   ` Mike Fedyk
2003-09-04 21:16     ` James Clark
2003-09-04 21:50       ` Mike Fedyk
2003-09-04 22:10       ` insecure
2003-09-04 22:01     ` jdow
2003-09-04 20:29   ` Rik van Riel
2003-09-04 21:12     ` James Clark
2003-09-04 21:40       ` Alan Cox
2003-09-04 21:41       ` Bartlomiej Zolnierkiewicz
2003-09-04 22:19       ` Jamie Lokier
2003-09-04 21:29   ` Richard B. Johnson
2003-09-04 21:51     ` James Clark
2003-09-04 22:06       ` Alan Cox
2003-09-04 22:10       ` Martin Mares
2003-09-04 22:23       ` Gustav Petersson
2003-09-05 17:52       ` Valdis.Kletnieks
2003-09-05 18:31         ` James Clark
2003-09-05 18:59           ` Martin Schlemmer
2003-09-05 19:12           ` Dale P. Smith
2003-09-05 19:45             ` Stan Bubrouski
2003-09-05 19:59           ` Richard B. Johnson
2003-09-05 20:01             ` James Clark
2003-09-05 20:08           ` Mike Fedyk
2003-09-05 21:15           ` Valdis.Kletnieks
2003-09-05 23:19             ` Bernd Eckenfels
2003-09-10 20:50     ` Timothy Miller
2003-09-10 20:48       ` Richard B. Johnson
2003-09-10 23:22         ` James Clark
2003-09-10 23:58           ` Greg KH
2003-09-12 20:51         ` Timothy Miller
2003-09-12 20:55           ` Tim Hockin
2003-09-15 11:39           ` Richard B. Johnson
  -- strict thread matches above, loose matches on Subject: below --
2003-09-04 22:41 Chad Kitching
2003-09-05 20:53 Chad Kitching
2003-09-05 23:30 ` Mike Fedyk

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=200309031850.14925.jimwclark@ntlworld.com \
    --to=jimwclark@ntlworld.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mochel@osdl.org \
    --cc=rml@tech9.net \
    --cc=root@chaos.analogic.com \
    /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