Re: You could do worse than Mach ports

[Peter da Silva <peter-dragonfly@xxxxxxxxxxx>]

First, the dragonfly message ports could cheaply act as a proxy to a 
more heavyweight messageport where that's needed, so the current design 
doesn't exclude Mach message ports or anything else weird and wonderful 
you want to layer under them.

Terry Lambert wrote:
> For anything that does anything interesting, you are going to have
> to map file data as well as metadata pages into the address space
> of whoever handles operations on the vp; specifically, here are the
> classes of manipulations, with a few examples of each:

> 	QUOTAFS		Implement quotas for all FS's
>
> 	UMSDOSFS	Implement UNIX permissions, etc., on top of
> 			FS's which don't support it

I'm not sure why either of these would require doing anything more with 
the user data itself than passing it through unchanged, unless you 
decided to store this metadata inline with the file data... which is 
probably not the optimal design. :) Even if the metadata is stored in 
the file you can keep it in a fixed size block and just adjust offsets.

Transformation, yes. You would need to add a more extensive operation in 
the middle... but I'm not sure how having the normal path not touching 
the user data excludes this.

> 3)	Directory folding, where you obtain multiple forks for files and
> 	implicit association of metadata, with the ability to back up
> 	and restore the resulting information, and have it functional
> 	afterwards.

Again, the data fork wouldn't normally be touched by any of this.

 > 4)	Semantic layering, where explicit semantics are implemented on
> 	top of the underlying FS, without needing to store specific
> 	additional metadata.

Again, you're not goin to touch the content of any data pages, so why do 
they need to be in your address space?

> Probably, whatever you call your message port or how you end up
> implementing it, you are going to have to treat it as a unit with
> the mapping across protection domains interface, in order to avoid
> any races between mapping and then operating on the mapped objects
> (given your stated out-of-order execution model).

Even if this is necessary in special cases those can be handled by 
making the Send() function for that message port point to the 
heavier-weight message call, or have a proxy message port that then 
redirects messages to one or the other if there's only one "syscall" 
message port per process.

There doesn't have to be... in fact it would make things more flexible 
if there was a message port associated with each file descriptor even if 
most of the time that pointed back to the system port.