Re: Thoughts for discussion & info request

Dave wrote:

> I've already been going through some of the device servers doing this
> before the next release. Certainly rs232, wd and fd now allow the namer
> "name" to be specified as a command-line option. I think what's tended to

Good :-)

> happen is that as there's been a need to allow multiple instances of a
> server, the capability for allowing user-specified names has been added.
> The filesystems came first as there are often multiple instances. Until
> rs232, fd and wd were modified to allow additional hardware config details
> to be specified there was only ever one instance, and thus only one name.
>
> Things such as nvram, joystick and mouse servers are really only going to
> have single instance (alright, I know I can have multiple mice, but I've
> never seen anyone use two :-)). It's a pretty trivial mod to make however.

Yes, the're going to have a single instance, but that doen't matter:
1st: It's a question of unification (or even called polymorphism). If
I used different schemes I'll allway have to remember which one is
appropriate. My brain is sometimes too small for that.
 (What would you say, if the c-compiler would require you to not a
  multiplication for integers like 2*3 while for floats like *(2,3).)
2nd: With the mouse we here got into deep trouble at exactly this
point. (We had worked with an similar system written some years ago.)
Imagine, you have a mouse server with 2 buttons and a client for it.
Now you have a second client which needs a 3 button mouse. Both call
their server /dev/mouse. Great dilemma. If you extend the 2 button
server to emulate the 3rd button, you may break the 2 button client.

The solution would be, to register both servers under a new, different
name. Say the old 2 button one as /dev/mouse2b, the new (build on to
of the old) als /dev/mouse3emu. Then you may bind the name /dev/mouse
to /dev/mouse2b in the namespace for the old client, and to
/dev/mouse3emu for the new client.
(BTW: how would that be done in VSTa???)
But how the hell, should the author of the old 2 button server know
that it will ever needed to do such? He can't!

That reminds me to an older discussion about a gnu readline server.
(I didn't say anything to it because I just felt other than Andy's
mind, but know I have an argument.)

In the former discussion Andy wrote (cited from memory):
The readline can be done in the library, so it shouldn't go to a
server. And expressed that code should go as less as possible to the
kernel, better to a server, best to the library.

A don't disagree in general, because for a heuristic decision it is
really the best way. But in the special case he is wrong. Why?

All server can be viewed as a meta abstraction of a service. The
flexibiltiy this provides is that inside your code you haven't to
worry about how the server works. As long as you make allowed requests
the server is responsible to do so. (If it fails, don't change the
client, fix the server.)
Because that fact, you can exchange a server with another one to meet
your needs. That is to change the implementation of a meta system in a
opaque way.
In other words, whenever some detail may be changed without disturbing
what is build on to of this detail, a meta abstraction is appropriate.
In a c/s system this is called a server.

Now for the readline: it is really a server itself, even if it doesn't
use help of the system to be a server.
It provides some service, i.e. to deliver a command line. In an opaque
way (from the client view), it let's you edit the command line.
In fact it is really more the only a server, it has a meta interface.
At this interface you may change to the vi or emacs behavior or you
may change it completly.

The very best solution to have things like that done in c/s systems is
to complete remove such code from clients (i.e. programs) and have a
server avialable. When the system boots there is no need to load a
server like the readline. Imagine the all the system (in a special
case) does is to run some scripts and it is controled by the mouse, a
server which one behaves like the plain unix kernel is full
sufficient. But if a user likes all the programms to behave like a
readline, a server may be started and shadow the name of the old one.
All programm started later will have the readline, even if the where
written bevor the readline were invented.

The problem, we have is, that at the compile/link time all the
abstractions made and stored in the same system get dissolved, while
meta abstractions get dissolved when they are used.

> > 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.
...
> > 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?
...
> I've probably misunderstood something here, but I think that the code in
> libc/mach/exec.c already does a lot of this. Perhaps with a bit of work
> this could be made to do something similar to what you mention.
>
> As far as having a loader server goes, I've always found the concept a
> little awkward. The cleanest solution I've come across is the mechanism
> used in the Oberon system, where the bootstrap code loads a loader at the
> same time as the kernel. All of Oberon's "libraries" are demand loaded, and
> this module does the demand loading. I guess you're thinking of something
> similar?

Exactly.
Beside thinking about relativ "easy" (with respect to the mechanism,
not the efford to code) things like an exec-server, I think about a
way to move the scheduling algorithms (for cpu and memory) out of the
kernel, but I didn't come to a clean solution yet.
(That's way I asked, in my mail, where the algorithm is. From Andys
mail I read, the decision for the RAM is made in the kernel, while the
one for the swap space is made in the swaper. Am I right?)

  BTW: Andy told me to look for the algorithm in some BSD book.
  Recently I tried to lend for books from the university library here.
  All 4 times I was told that it will take 4 to 8 weeks to get it.
  Yeah, they are really slow on ISBN # started by a 0! Scince the iron
  wall has fallen it is at least as dark as bevor east of the line.
  The only way to get recently info's is by the internet. But about
  1000 students and the stuff shares a 1200 baud line...
  For this reason I have a little fear, what solution may I have to
  invent when the remote-svc is up.
Received on Sun Aug 14 04:36:34 1994