Re: You could do worse than Mach ports

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

Terry Lambert  wrote:
>That was also kind of my point, when I pointed out the problem
>space mapping potential of at least examining the Mach model: in
>order to handle this type of thing, it can't be something you
>glue on at the back end, it has to be something you allow for,
>up front.

I'm not sure why you need to allow for it more than is currently
being done: any messaging mechanism can be slotted into the
Send() method, including Mach's.

You *would* need to have some kind of automated template
driven marshalling (this is a READ, copy arg1, create a handle
to arg2, copy arg3...), but that's all. So by "allow for" do you
mean more than "don't go hog-wild on the message formats"?

That seems reasonable.

>No, I was specifically referring to the quota and attributes
>files, which are stored on the FS itself, and which affect
>the directory operations, if you want to hide them, and the
>file operations, if you want to protect them from being changed
>by anyone other than the stacking layer.

As I understand it, the mechanism by which you make a
system call from a user process is the same Dragonfly
message you're using in the kernel, except in the kernel
it's faster. So there's no difficulty creating and operating on
these objects: whether you have easy access to *user*
data blocks or not, you do have access to your own!

And since all the access is going through the stacking
layer you still don't need access to the actual data blocks
going to and from the userland to keep the userland
from seeing them, you just filter the results from the
glob-analog call. The only place you need to take on
the extra overhead is where you're doing it anyway.

>  In the quota case,
>you have to take a pretty heavy-weight view of what constitutes
>memtadata, as well, since you have to deal with file extends
>via write, which means you need to peek at the bytecount for
>payload, and return value in case of success/failure.

OK, either you or I are very confused here.

Matt: could you comment on this?

But these are in the message, not in the data blocks. You have
access to the message... it was copied into the kernel with the
Send()... you just need to take a protection barrier transition to
access any data pointed to by the message.