DragonFly BSD
DragonFly kernel List (threaded) for 2003-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: You could do worse than Mach ports


From: Peter da Silva <peter-dragonfly@xxxxxxxxxxx>
Date: Thu, 17 Jul 2003 16:54:07 -0500

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.




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]