[Projectudi-tech] Re: [UDI-Tech] Copy avoidance in UDI?

[Deven T. C. <de...@ti...>]

On Thu, 10 Jul 2003, Burkhard Daniel wrote:

> So, because you have nice opaque concepts for memory, you can pass memory 
> "objects" back and forth and the encironment is always in control, and won't 
> copy data unless it really has to.

This makes sense.  Of course, this only accounts for "ownership" in terms
of who (the UDI driver or the UDI environment) is supposed to be messing
with the data in question.  If memory protection is involved, it might be a 
bit more complicated...

> To that effect, UDI uses reference counts in memory blocks (components of 
> buffers), and will at one point support copy-on-write for those.

I take it that a buffer is composed of a series of memory blocks, while 
"movable memory" is always a contiguous block, but might be moved to a 
different address anytime the environment is in control?  Is a buffer 
necessarily implemented this way, or could the environment just as easily 
make buffers also use contiguous memory?

You're using reference counts?  When would there be multiple references?  
Are identical blocks shared between different buffers?

> > Would this be difficult to do if starting from scratch?  Suppose I write a
> > new OS.  I'm thinking the right approach would be to start with a very 
> > solid message-passing mechanism in the kernel, and design it to move 
> > messages between contexts without requiring the data to ever be copied, 
> > with lots of cooperation from the VM architecture.
> 
> I think UDI's channel system is a very solid message-passing architecture. 
> Okay, you don't have much coperation from the VM system, but so far I 
> haven't seen any cases where we absolutely couldn't do something in the way 
> of copy avoidance with what's already there.

I'm assuming this message-passing architecture would have to cross memory
protection domains, which would require cooperation from the VM to handle
the floating ownership of the messages.  But since I'd like to use UDI as a
native driver interface (should I write this hypothetical OS), I'd want to
have the message-passing architecture either be the same as UDI's, or at
least compatible with it.  Even within UDI, I'd like to be able to protect
the system from misbehaving drivers, which means VM cooperation again.

I remember the message-passing architecture and I/O infrastructure of the 
Amiga's Exec kernel fairly well.  I always thought it was a well-designed 
system, unlike the horror that was AmigaDOS, which was slapped on top of a 
really solid kernel.  Of course, the memory management was simplistic, 
since the Amiga had no MMU, but the Amiga offered I/O completion ports many 
years before Windows 3.1 existed, much less Windows NT.  (Yes, I'm sure 
they appeared in VMS even earlier...)

On the Amiga, message passing was extremely efficient, since all processes 
shared the global address space, and there was no memory protection -- one 
task would allocate a message and send it to the message port of another 
task, which would later reply to the message, sending it back to the port 
of the originating task.  No memory copies were involved, and tasks behaved 
as a matter of convention -- between the time a message was sent and the 
time it was returned as a reply, the ownership was temporarily considered 
to belong to the receiving task, and the sending task was not supposed to 
touch that memory.  (It could, however, reclaim the message by canceling 
it, if it didn't want to wait for the reply.)

The Amiga supported shared libraries (which could be dynamically loaded 
from disk), and the low-level I/O infrastructure leveraged all these parts 
of the kernel.  An I/O device consisted of a shared library which followed 
a particular basic API, common to all I/O.  Certain device types extended 
the base I/O API with extra functionality.  (Sounds like UDI metalanguages, 
doesn't it?)  Each device had an associated task, which listened to a 
message port.  All I/O calls took the form of messages passed to the device 
driver task via its registered message port.  I/O requests were processed 
either synchronously or asychronously as desired.  It was a very clean and 
efficient architecture.  (AmigaDOS used message passing as well, but it was 
a complete mess because it was a Q&D port of a BCPL-based system...)

I'd like to have a system similar to the Amiga's in architecture, and it 
seems like UDI would fit well into such a model.  Of course, I'd want VM 
and memory protection (which was never quite feasible to retrofit into the 
Amiga even when MMU's became available).  And I'd like to design it all 
from the ground up to work as smoothly and as efficiently as possible.

Any particular thoughts on this?  I'm wondering if I ought to allocate 
messages to a granularity based on the physical page size, for memory 
protection reasons?  Or allow smaller messages, but from a "pool" where 
only messages are allocated?  I figure the VM system could give access to 
the page(s) containing the message to the recipient for the duration, but 
if smaller messages are allowed, this implies that memory outside the 
message proper would also be accessible.  (After all, I sure as hell don't 
want to page fault memory accesses to verify they're in the right range of 
the page for the message!)  Unfortunately, this could be a security risk, 
if that memory contains confidential data intended to be sent elsewhere.

Perhaps the best solution here would be to address the tradeoffs at the 
application API level.  I could have flags on the message allocation 
routines which determine how to handle it -- sensitive messages could be 
flagged as such, and probably allocated at the granularity of the page 
size, and normal messages could be allowed to share pages, despite the 
possibility of messages being seen be tasks other than the intended one.

Anyway, I feel like I'm rambling here.  Any particular recommendations on 
design here, when starting with a blank slate?

> > It seems like this would be a solid foundation to build UDI support upon, 
> > and otherwise make for an efficient, high-performance system.
> > 
> > Does this make sense, or am I on crack? :-)
> 
> No, you're asking exactly the right questions :-)

Oh, good. :-)

Deven

_______________________________________________
UDI-Tech mailing list
UDI...@pr...
http://lists.projectudi.org/mailman/listinfo/udi-tech