Reflection

Anders Petersson anders.petersson@mbox320.swipnet.se
Sun, 03 Jan 1999 10:28:55 +0100


>On Fri, 1 Jan 1999, Anders Petersson wrote:
>
>> The problem is that knowing the meaning of reflection doesn't bring you any
>> closer to the implementation of the OS. The idea is so general that it is
>> no more than a vague goal. Tril has said over and over again: this can be
>> done with reflection. Yes, in most cases he's right, but that says nothing
>> about *how* reflection is to be achieved. Until someone finds
>> out/alternatively tells me, I regard this idea to be nothing but an
>> achademic property to strive for in the design.
>>
>> It's like saying "our OS will be fast". You can say the system will be
>> good, since its speed will solve this and this, but if you don't know *how*
>> it will achieve its speed, you're in trouble.
>
>Yes that was the intent of that post.  I realize the details are not
>specified.  We in the tunes project are working on it.  Actually, it might
>be far off, maybe even the last thing added.  Consider it the final goal,
>maybe.

The word that comes to my mind is "vague". And maybe "unrealistic", or
"without contact with reality".

>Here is something to think about. How to make the Linux kernel reflective? 
>Put a compiler in the kernel.  Put the source code in the kernel.  Put
>functions to view and manipulate the source code in the kernel (I mean a
>syntax-directed editor). Then put in the last tricky function, which
>replaces the running kernel with a newly compiled one.  Presto, fully
>self-contained system [wait, add source code to the compiler, too!].  (No,
>you probably don't have enough RAM for this monster kernel to entirely
>fit. But swapping code in from disk has been done already.)  BTW, if you
>don't put any of this in the kernel, but you still have it all, you have a
>reflective system (but not reflective kernel).  Only the last step is
>really bad, because it requires rebooting :) 

All that in the kernel? No way. That rules reflective kernel out. Besides,
I see no need to have all that in the kernel to replace it without rebooting.

>> Could mOS support reflection? It does have some properties that makes it
>> more suitable for reflection. Each system is devided into lots and lots of
>> small units, each one (or the vast majority) movable, and replacable in
>> real-time. Updates are also noticed as they are done, not by a reboot.
>
>Sounds good so far.  Just consider the above example for mOS, instead of
>Linux, and you will get an idea of what you are up against.

Keep your reflective hands off mOS. :) We're aiming for a small-sized
kernel, not a reflective giant.

>Remember, every system has reflection.  It's just how long the road is
>(and how bumpy) from one system to the changed system. 

Don't forget that there's a prize for everything. Will the advantages with
good reflection weight heavier than the disadvantages? (I bet you answer
"yes"...)

>> What speaks against is that mOS shows the user the true system topology. It
>> is not as I understand Tunes does - to present the user with a view that is
>> independent of the underlaying structures.
>
>There is a view that is independent of underlying structures, but the user
>can cross it.  Normally there will just be a warning message that says,
>"if you go here and change stuff, it won't be platform-independent
>anymore."  You can still do stuff there, and it's all still objects.  I
>expect lots of hackers to do this.  It will be necessary to spend time
>here in order to find optimizations to make the system fast.

Blurry, blurry.
Who was speaking about platform-dependence? Maybe the only thing in Tunes
that's platform-independent is that user view? Well, in UniOS the true
system is platform-independent, except for low-level drivers and maybe
binary executables.

>> As reflection changes the way
>> the system is structured, without any help from the user, reflection could
>> confuse for the user by changing the way *the user* sees the system. 
>
>Well, it could be done with the help of the user.  Anything in Tunes can
>be done either with, or without, the help of the user.  Usually the user
>helps first, then when s/he is comfortable with what is going on, sets it
>on autopilot.  (this is true for every action in the system, not just
>reflective activities.)

I'm sorry, but without more concrete ideas, the above remains to be just
words for me.

binEng