Micro Kernel Question

[Francois-Rene Rideau]

On Wed, Jun 30, 1999 at 09:17:43PM -0400, Pat Wendorf wrote:
> Francois-Rene Rideau wrote:
> 
>> PS: on a completely different, I made an analysis of reasons
>> behind the failure of HURD as an OS architecture,
>> which I published some time ago in the TUNES Glossary:
>>         http://www.tunes.org/papers/Glossary/index.html#microkernel
> 
> Wow, that one was a real eye opener.
Thanks a lot for your appreciation.

> I take it what you're saying is
> that Linux is better than Mach,
No doubt about it.

> but a system of Interconnected high-level compiled and
> optimized software is better?
Sure.

> I imagine it might work, but aren't you just
> providing actors which provide the same functionality
> as the discrete modules of the uKernel?
I'm doing more than that.
Hans Reiser wrote an article about his ReiserFS
	http://devlinux.com/namesys/
that impressed me as to
how he had a similar idea of the Right Thing(TM) as I had
regarding motivations underlying the design of his filesystem:
by providing a single abstraction level instead of several levels
(uniformity in our HLL specs; what our friend BRice calls "homo-iconic")
you optimize the expressiveness/complexity ratio,
and avoid the impedance adaptation problems due
to interfacing foreign abstractions.

This was all summed up pretty well in Alan Perlis' 1982 epigram collection:
	http://www.cs.yale.edu/~perlis-alan/
Alan Perlis epigram #9:
	It is better to have 100 functions operate on one data structure
		than 10 functions on 10 data structures.
[Alan Perlis' epigrams: Snuff'em, grok'em]

Again, if you re-read the Tunes FAQ (that I expanded recently),
	http://www.tunes.org/Tunes-FAQ.html
you'll see that no single feature of Tunes is ground breaking;
the heart of the Tunes Project is its uniform reflective architecture.

> Couldn't that end up being a mess anyways?
Why so? There certainly is an inherent unvoidable complexity
in every programming problem. So a useful notion of "a mess"
can only be about adding _unnecessary_ complexity to a problem.
In my article on Metaprogramming and Free Availability of Sources
	http://www.tunes.org/~fare/articles/ll99/index.en.html
[Please send any corrections, english translation lift up, etc],
I argue that metaprogramming and reflection allow
to alleviate the complexity of programming rather than increase it.
And again, uniformity only removes the complexity of interfacing
abstractions with foreign semantics and incompatible granularities.

> When I was planning UniOS, the same idea of kernel less design came up,
> but there were implementation issues we just couldn't get around.
> For example, there must be a way for objects to communicate with each other,
> but how do they know where each one is in memory?
The right answer to your question is MU.
When in C you have function main() call function foo(),
how does it know where function foo() is in memory?

> For that I think you need some kind of area of memory that is
> dedicated as a symbol dictionary of sorts?
If you want dynamic linking by name, then you'll indeed have the equivalent
of a dictionary/directory/symbol-table/foo somewhere. So what?
Note that Linux has many different ways to associate values to names,
each with a completely and annoyingly different interface:
filesystem directories, ELF symbol tables, libresolv, libProplist,
lots /etc/* or ~/.* files each with its own conventions, etc.
Not to talk about nameless but numbered concepts such as file descriptors,
IP&port addresses, inode numbers, process and user IDs, etc.
Tell me about one hundred data structures each with ten accessors,
instead of ten data structures each with one hundred accessors!

Tunes will provide a uniform _interface_ to key->value associations
independently from their uniform or non-uniform _implementation_.
Certainly, there will be memory _allocated_ for such associations,
but it need not be specifically _dedicated_ to them.
Just treat association tables (a-list, hashes, *-trees,
pick your fav'rite implementation of the day) as any other data structure.
So, some of these data structures will be used by metaobjects? So what?

> Or possibly an actor handling actor,
> which I guess would classify as a kernel wouldn't it?
Certainly not. A meta-object, perhaps, but not a kernel:
it doesn't centralize all execution; it isn't a compulsory object to use
(other developers can use different metaobjects if they want;
if needed, code could dynamically migrate to another metaobject at runtime).
Or perhaps you think that CAR and CDR are the kernel of LISP?
Well, since LISP is so dynamic, people can stop using CAR and CDR,
and the implementation of CAR and CDR can itself be changed.
So what's kernelish about them?
The onliest and mostest pervasive concept in LISP is function application.
So is function application the kernel of LISP? Where is it?

[ "Faré" | VN: Уng-Vû Bân | Join the TUNES project!   http://www.tunes.org/  ]
[ FR: François-René Rideau | TUNES is a Useful, Nevertheless Expedient System ]
[ Reflection&Cybernethics  | Project for  a Free Reflective  Computing System ]
Let not your wish to be the same overcome your wish to be useful.
Let not your wish to be different overcome your wish to be useful.