From: Ingo Molnar <mingo@elte.hu>
To: "T. J. Brumfield" <enderandrew@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: about modularization
Date: Fri, 3 Aug 2007 17:02:09 +0200 [thread overview]
Message-ID: <20070803150209.GA13619@elte.hu> (raw)
In-Reply-To: <cdc89fe60708030652p634c6ea1y1f7b351f12a35a7a@mail.gmail.com>
* T. J. Brumfield <enderandrew@gmail.com> wrote:
> On 8/3/07, Ingo Molnar <mingo@elte.hu> wrote:
> > snip...
>
> Except that a working prototype of plugsched exists and functions
> exactly as advertised. [...]
a prototype for dynamic syscalls exists too. A prototype for pluggable
network IPv4 stacks exists too. A working implementation existed for
STREAMS too. Existence of a patch still does not make any of them a good
idea for the core kernel.
[ If existence of a patch was the only criterium for upstream merging
then we'd have a much poorer quality Linux kernel today. Odds are that
in that case you would not even know what 'Linux' means, it would
still be an obscure, niche hacker's toy somewhere on the 'net ;-) ]
> [...] I understand that modules can be loaded and unloaded, where as
> other aspects of the core kernel can't just load/unload as the kernel
> is running, but the cpu scheduler could be selected at boot via a
> command line, or as a kconfig option when compiling like the io
> scheduler.
i replied to that in my previous mail:
But the kernel core, which does not depend as much on the physical
properties of the stuff it supports (it depends on the physics of the
machine of course, but those rules are mostly shared between all
machines of that architecture), and is fundamentally influenced by
the syscall API (which is not modular either) and by our OS design
decisions, has much less reason to be modularized.
But to put it in different words:
_certain core kernel code should not be pluggable_
and whether it should or should not be pluggable is an entirely
technical decision, up to the maintainers of that code.
> And while the io team may feel that it would be best to have one
> scheduler that worked well under all circumstances, often this can't
> simply be the case. [...]
you skipped the bit where i pointed it out how different CPU scheduling
is from IO scheduling. Plus now you are arguing against the opinion of
an IO maintainer too? :-)
Ingo
next prev parent reply other threads:[~2007-08-03 15:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-03 12:07 Scheduler Situation T. J. Brumfield
2007-08-03 12:31 ` Alistair John Strachan
2007-08-03 12:52 ` Oleksandr Natalenko
[not found] ` <192840a00708030616g22d9dd16o95b2620bfe3347a8@mail.gmail.com>
2007-08-03 13:27 ` Андрій Мішковський
2007-08-03 13:45 ` Alistair John Strachan
2007-08-03 13:00 ` debian developer
2007-08-03 15:28 ` about modularization Ingo Molnar
2007-08-03 13:19 ` Ingo Molnar
[not found] ` <cdc89fe60708030651s54b5f0e0j938450632cf621c5@mail.gmail.com>
2007-08-03 13:52 ` Fwd: " T. J. Brumfield
2007-08-03 15:02 ` Ingo Molnar [this message]
2007-08-03 15:13 ` Ingo Molnar
2007-08-03 17:47 ` Rene Herman
2007-08-03 18:59 ` Ingo Molnar
2007-09-01 22:02 ` Oleg Verych
[not found] ` <200708031354.15485.alistair@devzero.co.uk>
[not found] ` <cdc89fe60708030712q391de609o3999a870ea7cbcbd@mail.gmail.com>
[not found] ` <200708031540.29687.alistair@devzero.co.uk>
2007-08-03 14:51 ` Scheduler Situation T. J. Brumfield
2007-08-03 15:05 ` Alistair John Strachan
-- strict thread matches above, loose matches on Subject: below --
2007-08-06 20:20 about modularization Mitchell Erblich
2007-08-06 20:50 ` Rene Herman
2007-08-06 21:48 Mitchell Erblich
2007-08-06 23:35 ` Rene Herman
2007-08-06 23:45 ` Rene Herman
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=20070803150209.GA13619@elte.hu \
--to=mingo@elte.hu \
--cc=enderandrew@gmail.com \
--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