Thoughts for discussion & info request

Hello,

this is going to become a longer mail, thanks for your patience.
I have 5 topics:

0. Intro

While working on my thesis I came to the point, that obviosly most if
not all reliable, clean, elegant ... system designs all follow a
particular structure. This structure is also found in natural language
and scientific theories and something more. At least this applies to
designs like smaltalk's MVC model, ETHOS's carier/rider seperation,
CLOS, Sather's abstract classes and renaming scheme, "clean"
client/server systems, modern interrupt handling and interrupt
dipatching to tasks.

But before I go on to write it finaly down and to realize that I may
be wrong I need some more examples. From what I know about VSTa I'm
sure it makes a good example.

1. first question

Could please anyone explain the mechanism of comunication in VSTa in a
somewhat detailed way. I don't look for the details of message passing
that is relative easy to see from the well commented code. My question
is more like: is the port number something like a unique identifier of
a server, is the name a client knows for it something like a alias or
more hard coded, is it possible to have different names for the same
server in different client views?
(The question may make a fool of myself, but at this abstract view it
is hard to read it from the code whithout to risk a wrong guess. And
at the time I'm not about to become a VSTa wizard.)

2. another question

Same as above for the paging mechanism. How is it embedded in the
system.
I had a view at the swap server source, but I didn't manage to find:
- where the decicion is made which page is to swap out or in
- where the page is transfered (may be from the kernel?)
- how the pager is activated
and so on.

For the two things above, when I'll have it understood, I'll go on to
prepare some pages of paper. It shouldn't be the problem to translate
it to english to help extending the poor documantation of VSTa.
(Please would someone take the time and correct my english than :-()

3. reflections about the (initial) registered names

For theorie *inside* an object (like an server or an object in obj.
oriented manner) the name it has in the context it is used in has no
meaning at all. (I think it's not worth to found this more; everyone
refers to self by I not by it's 1st, 2nd or nick name.)

The name of everything has a meaning only in the context this thing is
refered / used in.

Furthermore everyone how reflects about bindings (for names, classes
and so on) comes to the statement: the later a binding is done, the
more is known about the conditions, thats why the decicion get better.

So far. Now when I have a look at the sources, there exist 2 way the
name a server is registered under get determined. For some (good in my
mind) examples, the name is provided at start up time by the command
line (bfs, dos, tmpfs). But for some other it is hard coded.

Sure, at this time, while the system is as "simple" as it is, there is
no need not to hard code it. This degree of flexibility is not needed
yet. But what when the system extends?

So I propose to *generally* provide the name as a parameter and never
code it hard. At this time, this is not a great deal, and I think is
is worth the effort and pay in the future.

Any thoughts?

4. put the server main into the library

Going further the way from topic 3. Every main of a server will become
almost equal. It will:
a) get the name to register under from the command line
b) pass any extra command line option to a (proposed) init routine
c) register upon success under the given name
d) call the (proposed) server_main routine.

Why should it remain as a part of code copied for every server?

May be it will be worth to code the server_main loop in a library
function too. This had the disadvantage, that every server must
provide a function of the same name for every possible message, even
when some of them read msg_xxx(msg m, file f){}. But it had the
advantage of not carrying a long almost constant funtion in every
server.

Thoughts?

5. go one step further

I'm not sure if it is possible in VSTa, but with the above in mind, it
should be possible, to build a server which may be called loader.

This loader would allocate address space, memory, and an initial
process for every server and program. Load the code, initialize it.

So a lot of the exec system call could be moved out of the kernel into
a server. Not that bad.

May be this loader can later be modified to allocate only the address
space and memory as shared readable. So we'll have the basis for
shared libraries?

How about that?

So far. Know for a question which should *really* make a fool of
myself and the complete university too.

Nobody can tell me what a spinlock is. (Maybe I know it by another
name? I hope.) From the code it looks like a cpu freese
[cli()/sti()], but it's state and it former state is moved around for
any reason. Please can someone enlighten me?

/joerg

-----------------------------------------------------------------------------
Joerg Wittenberger
Rietzstr. 32b
01139 Dresden
Germany

email: jw@ibch50.inf.tu-dresden.de
       jw6@mail.inf.tu-dresden.de

WWW: <a href=http://www.inf.tu-dresden.de:8002/people/jw6/top.html>jerry</a>

PGP PUBLIC KEY: available on request or by finger
Received on Thu Aug 11 05:50:44 1994