Re: multi/tasking/processing

[rideau@xxxxxxxxxxxxxx (Francois-Rene Rideau)]

> Francois-Rene Rideau:
>    >       Nano- or Micro-, they are the same. The principle of a kernel
>    >    itself is deeply broken. What is a kernel ? Just some overhead to
>    >    dispatch routines at run-time. It just has no point. Code should be
>    >    bound whenever the binding is known, not before (not possible!),
>    >    not after (and at least, just once, not once per call).
> 
> Raul Miller:
>    > Er.. how do you re-use resources used infrequently by processes?
> 
> Francois-Rene Rideau:
>       What is the problem ? The same way as you always did, or any way
>    you like ! I do not see why you need a kernel to do that. Sure you
>    need resource managers and (dynamic) linkers, but I see no point at
>    a run-time dispatch center (well, until the 70s, dynamic linking
>    was too memory hungry, so a kernel was necessary).
> 
> I don't know if you're not paying attention to what you wrote, or what...
   Or maybe that's you...

> If you've dynamically linked to some bit of code, or dynamically
> inlined it, what do you do when you need to re-use the space occupied
> by the code?  At that point, your code isn't there any more.  So, what
> do you call the code which takes responsibility for implementing this
> re-use and managing calls to this code?  How is it implemented?  [This
> kind of code is the heart of any kernel.]
   Firstly, who's talking about linking being always dynamic ? Sure dynamic
is the general case, but for specific applications (e.g. embedded stuff)
are happy with statically linked programs. Now, if you want dynamism and
some reasonable lifespan, sure you'll have garbage collection. Have you
ever heard about GC ? Why couldn't I GC "code" as well as "data" ?
Or perhaps you'll call the GC a "kernel". Sure, again, if using a
statically linked program, you could call that a kernel, but then all
the statically linked program could. If not, then this is not a "kernel",
because I can dynamically modify and upgrade it at will. I forgot to
add to the definition of a kernel that it is a static piece of code.
So here is he definition:
"kernel": "a statically linked centralized run-time dispatcher".


> In some cases, the graph of process control flow is simple enough
> (e.g. linear) that redirecting the flow to adapt to re-using memory is
> trivial to implement.  However, there's stuff that has high implicit
> re-use, even if it's typically run once a day or once a week for
> months on end on some random system.
   Then what ? Again, GC is a well known problem with lots of well-known
techniques each having its constraints and its advantages.

> The kind of integration you're
> talking about is only going to be workable if the entire system has a
> cohesive overall design goal
   Sure, the low-level binary image is cohesive. But why should the programmer
have to worry about enforcing cohesion ? Have you heard about high-level
languages ? Without denying the interest of low-level languages, technology
is (potentially) ready for people to efficiently use but high-level languages,
using secure semi-automatic tools to safely give efficient low-level
implementations for them (=automatic optimization, computer-verified
hand-optimization, and super-user-admitted implementations).


> -- some systems are composed of a variety
> of components from different sorts of vendors.
   Why do you assume components should be distributed in statically linked
lowest-level form ? This shouldn't be the case. You can already distribute
source and recompile in a different environment. And systems like Dylan
pretend to remove this stubborn constraint by allowing black boxes to be
dynamically linked.


> There are some systems where this sort of functionality is not
> implemented in any general fashion (e.g. embedded systems which have
> enough real memory).  There are other systems where this sort of
> functionality is implemented in a general fashion (e.g. systems which
> have a kernel).  The distinction between these kinds of systems
> generally has to do with the nature and volume (variety) of their
> communications.
   What do you mean here ? I already reckoned that there was a one
interest in kernels: saving memory when one needs dynamic binding but
hasn't got enough memory for buffers.


> If I'm building a system that needs to communicate many megabytes (or
> terabytes -- I'm trying to be qualitative here) of information per
> day, in a bursty fashion, with some of it preserved for arbitrarily
> long intervals of time, I'm going to start wanting the features a
> kernel provides.
   Why ? All you can do with a kernel, you can do better without
(or with an "exokernel"). If you want dynamic linking, use
dynamic linking (ok, you need some memory for buffers). If you want
fast messages, send them directly. A Kernel in no way can improve
throughput, but on the contrary will drastically reduce it if using
fine-grained programming.

> On a fine-grained level, the value of a system is determined by the
> cost of doing without.  This is true for kernels, shoes and food.  The
> cost of a system is determined by market issues (value, availability
> and competition).
   Yes, so what ?

> When you say "the principle of a kernel is deeply
> broken," I'm not sure if you're saying that it has trivial value or
> excessive cost.  I feel that there exist applications where kernels
> have trivial value and a high cost -- but I know this is not true of
> all applications.
   The value of a kernel lies in the functionality that's not part of
the kernel (centralized dispatch) design. The cost is inherent to
any centralized design, and is 100% of kernel execution time in
micro-kernels, that have all functionality removed.
   A kernel (and centralization in general) is just bad factoring and
lack of use of information; only is sometimes saves a little resource,
and is faster to design. When you use a kernel (in the meaning of a
static centralized run-time dispatcher), you can always do better without
in time as well as space,using dynamic|specific|bind-time|linker.
   Sure sometimes, you need a generic run-time dispatcher. Then it's
called an interpreter, not a kernel, and needn't/shouldn't be
centralized (at least conceptually). It's value: to save space.

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/";