Re: Thoughts for discussion & info request

Hi,

I'll leave some of the details as I expect other people may be able to
answer some of your questions from a better "theoretical" perspective. I
think I may be able to comment on some of the implementation stuff.

Wittenberger wrote:
>
> 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?

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
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.

> 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.

A couple of the servers already do something similar to (b) and (c) already.
Unfortunately it seems (to me, but I'm no guru on such things) that
initialisation sequences vary depending on what's being initialised.
Certain types of server will always have the same sort of initialisation (eg
filesystems), but some of the device servers do things in all sorts of
orders.

This is quite similar to the situation with FS_STAT/FS_WSTAT messages - by
allowing each server to do things how it likes (just adopting a convention
for a small number of details) we have maximum flexibility, but it makes
unifying things more complex.

I've found that this freedom is very useful as it allows making use of
device specific details very easy, without sacrificing the the clean
FS_READ/FS_WRITE type mechanisms used in normal operation.

I think though that there may however be a good case for putting some
command line option handling into a library.

> 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?

I thought about this a while back (although I never has time to try it).
The biggest problem I could think of would be that we'd replace a large
switch statement with a data structure that had a slot for each function
that could be called as the result of a message being received - there are
currently around 20 of these. In practice most of the servers don't handle
all of them (often far fewer). The other effect I could envisage would be
to create lots of little functions, and I suspect then end result will be to
expand the overall size of the source files.

Another idea I've discussed with a couple of people however, was the
possibility of a file-system library. Certainly generalised data/block
caching would be pretty simple, and with a bit of work we could use one
library base to provide all of the filesystems with multithreading and
common features. vstafs has the most different features of all of the
filesystems - it's fairly simple to see how caching of blocks is just a
subset of caching runs of disk sectors. bfs and dos have almost identical
block caching code, so it gets simpler every time one considers the problem.

Other library posibilities exist for merging some of the mouse and joystick
code, and some of the fixed disk code's already been put into libdiskfs.

> 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?

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?

                Regards,
                Dave
Received on Thu Aug 11 13:16:15 1994