Re: VSTa - First Impressions

[David Jeske <jeske@ux4.cso.uiuc.edu> writes:]

>First, Shared Libraries. How did they end up getting implemented? Is there
>an archive of the "shared lib mailing list"?

No, creating the list made it all quiet down. :-)

The short version is, you link against a library of stubs, one per entry
point. All the stubs call a little bit of code which maps in the shared
library loader, and passes the requested library and entry point to it. The
current loader maps in the real library, and calls the code.

All entries are done via a table, which is at the front of a shared library.
Thus, detecting a NULL pointer for the table causes the load; thereafter,
the vector is pulled from the table and the routine called directly.

>... The archives
>would be great, because if there are reasons that some methods were decided
>against (shlib server, etc.) I am interested in knowing what they were.

Mostly, simplicity. More to the point, I was on the road, had some time,
picked a way, and went for it.

>Also, what happened to the idea of "moving the scheduler out of the kernel"?

That was never seriously considered.

> Going with the "less in the kernel is more" idea, why wasn't this
>discussed?

Well, I used not so much the philosophy "everything possible out of the
kernel", but the quite different "put enough in the kernel so hereafter you
can stay out".

> I think that allowing the flexibility to write your
>own scheduler is on of the more interesting prospects of a microkernel,
>and being able to do so while retaining compatibility (read, no source or
>binary changes) with the "microkernel proper" is enticing. However, I'm
>not really aware of possible performance penalties.

They can be significant, although several operating systems have devised
interfaces efficient enough to be acceptable. Often they involve having the
scheduling process identify numberous processes all at once, which are then
run in order until the list is empty.

These schemes usually pick up a lot of complexity when faced with changing
priority situations, for instance.

>CVS. I have had some limited experience with CVS and I agree with those who
>suggested it's use for the management of the project source. Andrew said he
>was going to do this, did it happen? (this is more a bit of curosity than
>anything I guess).

CVS (remote version) requires rsh access, which is incompatible with
firewalls.

>Is this an official term? I have seen Andy refer to this as "VSTa protection"
>and such too. I read one of the Plan9 papers which didn't make any mention
>of Capabilites (as far as I remember). Is this a Plan9 term? It seems that
>especially in the VSTa white paper, "Capabilities" seems to be almost a proper
>term for the VSTa system of security.

Nope, this is unique to VSTa.

>More importantly, is this term one which should be perpetuated?

I don't think we've settled on an accepted terminology in this area. Since
I'm involved with Kerberos these days I find myself using some of their
terms, now that I've learned them.

Glad you found VSTa, hopefully we can load you down with work! :-)

                                                Andy
Received on Fri Dec 9 14:25:13 1994