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

On Wed, Sep 03, 2003 at 06:53:01PM +0100, James Clark wrote:
> 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

And this interface will look like what?
What is wrong with the current kernel API interface?

> 2. Over time remove most existing kernel 'drivers' to use new interface - This 
> is NOT a Microkernel.

"remove"???

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

So "drivers" are a third class citizen?  They don't need to be under the
GPL for some reason?

> Expected Outcomes
> ------------------------
> 
> 1. Make Linux easier to use

How would this help this?  The kernel would get bigger somehow, right?

> 2. The ability to replace even very core Kernel components without a restart.

We can do that today with modules.

> 3. Allow faulty 'plugins' to be fixed/replaced in isolation. No other system 
> impact.

How are you going to isolate parts of the kernel from itself?

> 4. 'Plugins' could create their own interfaces as load time. This would remove 
> the need to pre-populate /dev. 

What?

Ok, I'm just giving up now.

But remember, patches are always welcome.  Please post your code to
implement this system if you come up with some.

Good luck,

greg k-h

  parent reply	other threads:[~2003-09-03 18:21 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-03 17:53 Driver Model 2 Proposal - Linux Kernel Performance v Usability James Clark
2003-09-03 17:49 ` 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 [this message]
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=20030903181818.GB1532@kroah.com \
    --to=greg@kroah.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=jimwclark@ntlworld.com \
    --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