Re: got linux version running... now what?
Phil Frost <indigo <at> bitglue.com>
2005-07-12 17:16:13 GMT
On Tue, Jul 12, 2005 at 12:00:06PM -0400, Robert Brewer wrote:
> Thanks for the tips, I built the user-space linux version of uuu from
> darcs and ran it.
> I poked around in the python interpreter and got the shell going,
> and also ran gatest.
I don't think gatest really applies to the linux version. Did it do
anything interesting?
> So now I'm again wondering just what it is I have. I've been wrapping
> my brain around capability-based systems and single-level stores
> for the past couple of weeks and liking the ideas. Also, I've gone
> through the past few months of mailing list archives and getting
> into Phil's insights on design. It seems that Phil's ideas are
> all about minimizing the impedance mismatch between what
> an application wants to do and what the underlying system
> abstraction supports, as well as carefully unifying similar
> abstractions as much as possible.
>
> The idea of no address spaces, no separation of kernel and
> user space sounded pretty strange, but upon more reflection
> I'm seeing that capabilities could allow that to work. The "kernel"
> can follow POLA and only give capabilities that each object
> actually needs, and with no other way to access those
> functionalities, there is no need for memory protection. Is that
> the idea?
That sounds like the right idea. Try not to even use "kernel" in the
context of unununium, because it doesn't really mean anything. The agent
that will be giving capabilities will ultimately be the user, although
quite often indirectly.
> When I look at it that way, I find myself wondering why
> we need MMU hardware. I start questioning a lot of
> things about today's systems. But then I figure a lot
> of that hardware must be there for a reason. I guess
> the MMU is still needed to efficiently manage the single
> level store. So rather than using its protection abilities
> to prevent "processes" from stepping on each other,
> its main purpose is to efficiently fault in pages and
> handle copy-on-write. The processes can't step
> on each other because they
> can't construct their own addresses, and so have
> no way of performing unsafe actions on other
> processes.
>
> On the other hand, it seems to me that for performance
> and convenience sake, there must be some different
> "layers" to what is happening. For example, I'd really
> like to pass around capabilities for space usage, processor
> usage, network bandwidth, etc. But every python
> function will need to use some space and some processor.
> Taken to its logical conclusion, I would need to pass
> a space-bank reference and a processor-meter reference
> into every function. I don't want to program like that.
> I would want a way of specifying defaults for those
> in a section of code. Would aspect-oriented programming help?
> Would I set some sort of global variable? Maybe I need a separate
> "capability stack" that is logically passed into each function
> I call. Its purpose is to pass heavily-used capabilities
> like space and processor time.
> Often I would pass the current frame on the capability
> stack to my next function, so I would do nothing. Most
> other capabilities would be passed as explicit arguments.
> Well, that's just some capability meandering...
The MMU is still needed to service page faults, just as it is used to
implement swap in any one address space now. If we had cpus with huge
address spaces, big enough to hold all data we would ever want, the MMU
would be sufficient.
However, anyone with even a small mp3 collection has more than 4 GB of
data, so there must be some way to reference it all. A VM of some sort
is already required for secure operation, so that VM layer can be used
to solve the small address space problem. In the VM, a reference will
not be a 32 bit pointer to some address space, but instead something
bigger. Maybe there will be some virtual 64 bit (or bigger...64 bits is
only 16 exabytes) address space, or maybe instead of pointers to some
location they will be sequential object IDs or, something like that. Of
course it would be terribly slow to implement this simply, so the VM
would need to perform some compilation to perform reasonably.
As far as holding references to commonly needed resources, each language
already has some way to deal with this problem. In Python for example,
references are received by __init__ and stored in a class instance;
methods of that class can then access them later. Functional languages
have closures, etc.
> So what are some items on the todo list? I see a lot of
> pythonized device-driver type of code in pymodules. Are
> they relevant with the Linux userspace version?
Probably not. Right now, Unununium in linux is nearly identical to the
python interactive mode. Most of the code is driver stuff that no longer
applies.
The next goal is to get orthogonal persistence working in some form.
There is some work in this area; take a look at
pymodules/uuu/linux/paging.py and pymodules/uuu/tstorage.py for a start.
Neither of these are beyond the experimental stage, so don't let them
box your creativity. One goal I did have in mind when writing them was
to keep the platform specific code to a minimum.
RSS Feed