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