11.3 resource allocation

[Mike Prince]

On Tue, 6 Dec 1994, Francois-Rene Rideau wrote:

> Well, I admit was not clear enough.
> There are 
> * basic, primitive, resources, from device drivers
> * (potentially recursive) resource constructors, that make resources from
>  other resources: for example, we may have a packet protocol as a standard
>  line multiplexer (so anyone can use any kind of raw comm. line to send
>  asynchronously any kind of objects). If some user/program has got part of
>  a line, he/it may want to multiplex it again, and a sub-user/program may
>  multiplex it again, and again. As for memory, there is a big memory object
>  in each host; it can be multiplexed by using memory allocators, and each
>  memory zone can be used with a sub-allocator, etc...
> * Finally, there are deconstructors/clients, that consume/use provided
>  services. If normal users/clients are not given access to the primitive
>  resources, they may  be unable to know if they are using the actual system,
>  or a virtualized one. Clients may well be providers themselves...

We are working on the same problem from two different vantage points; Fare
from the OO high end of constructors/destructors and inheritance, and I 
from the hardware implementation side.

You want as much versatility, I want that balanced with good speed.

My framework is meant to show HOW our system could work.  It is good to 
talk OO theory, but please address the implementational side of things as 
well.

Let's see if we can agree on a few things right off the bat.

Our OS is meant to exist in a very distributed environment.
	This is our GLOBAL layer.
It is composed of everything out there. This exists, period.  Lets name it.

Software will be distributed to users.
	I call these TOOLBOXES.
Remember, this is not the programming side, but the distribution side.  I 
have the feeling Fare believes that once I get a TOOLBOX from vendor X, I 
should be able to add functionality to it by inheriting its properties a 
la OO programming.  Is this true?  If it is we either need access to the 
source code, or our distribution format needs to be rich with information 
about our a TOOLBOXES internal routine names, data structures, etc.  This 
will slow re-compilation during migration of code to different 
computers.  It will also make our distributions fat.  I am leery about 
making such a compromise.

The alternative, is to have TOOLBOXES be black-boxes of functionality 
with multiple entry points and a versatile data-passing mechanism.

Stacks provide us this versatile data-passing method; almost anything can 
be handed in and given out.

The multiple entry points coupled with a tool boxes ability to 
advertise entry points and their capabilities.

Finally, if we break code up into discrete toolboxes we can manage 
migration more easily.

Fare, please address how OO programming practices would influence 
distribution format of code.  I.e does an application come in one big 
package, or is it a collection of code fragments that can be farmed out?

What shall we call these code fragments?
 
If the code can be farmed out, how do we manage intra-code and code-data 
dependencies in a distributed environment?

Assuming we can have 
subroutines, how do we retain the integrity of a return stack if an 
entire process is migrated (we can not simply remember the return address 
anymore, its more like domaincodename:offset)?  Then, how can we 
do subroutine calls/returns FAST?  I've gone on too long already.

These are implementational issues that must be addressed.  We cannot look 
at the ideal pure OO language.  We are looking at an *operating system*.
Everything must work together; programmers, hardware, users, etc.

BTW, holistically is not a religion, it is a way of looking at things.  
You recognize all the factors and then make a decision.

> So what I want to say is *NO ARBITRARY F?CKING LAYERS* in the system:
> what we need is not layers, but services. You don't build a hierarchy just
> for the sake of administratrivia. Your build an administration because you
> need services. Let's model the possible layers according to the actual
> needs measured, and not provide resources according to some administration's
> capabilities. That's liberalism vs. collectivism.

These layers are a framework, within which the pieces of our OS will 
fit.  Code does not just exist, it is located in memory of some 
computer.  At the very least we need terms to describe where this code 
is during our discussions about the OS, even if the code itself does not 
care.

To recap;
	The GLOBAL level exists.
	Code and data will migrate between machines so;
		How is it represented during transmission? I've suggested
		Toolboxes, tools, agents, and stacks.  Not to your liking,
		suggest an alternative.
	A DOMAIN is a useful way of corraling your resources.  Is there a 
		better way?
	CPU's exist. Drivers are necessary.  What will we call the space 
		these drivers are bound within?  I vote to call it 
		LOCAL.  When migrating resources, they are going 
		somewhere (a physical machine).  Again, we at least need a
		term for this destination.  
		
Bottom line, terminology limits you.  But we need terminology in order to 
communicate.  I have proposed names for things we have, and have 
suggested relationships between them.  If you don't like the names or 
relationships, suggest new ones, but don't throw out the baby with the 
bathwater.  Without names from things we talk about, we'll be a veritable 
Tower of Babel.

Mike