Hi,

another approach would be to combine all the resources that a network
service needs into a single resource container, which is managed in a
way similar to space banks, but using a separate management service (a
"network bank"?) that can only be used by privileged system network
services responsible for implementing the scheduling policy (ie, it is
not general purpose).

Only in a simple scenario would these network banks be equivalent to
spacebanks.  More complex semantics would allow for example to specify
I/O bandwidth guarantees as well.

There is some hazard attached to having two "classes" of memory, but
the system could provide a service to move resources from one type of
contingent to the other according to some policy.  In a dynamically
configured system there need to be ways to rebalance contingents of
resources anyway, so that seems to be a small price to pay.

One advantage of binding resources to a certain specific use in this
way is that the resource can be delegated easily for a specific
purpose.  Consider a web browser which I want to debug or monitor, for
example using intrusion detection techniques.  If the malicious code
can hide in opaque memory, this fails.  So I have to give only
transparent spacebanks to the web browser, but then it can't use the
network anymore.  Ouch!  By bundling some opaque memory into a network
resource object, I can give the web browser network access without
giving it direct access to opaque memory resources.

Of course some of this could be implemented in a user's shell based on
the EROS spacebank and factored network stack model.  The interesting
question is if conflating resources into a bundle at the system level
allows for more optimisations or more efficient resource scheduling.
Any takers?

Thanks,
Marcus



_______________________________________________
L4-hurd mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/l4-hurd

Reply via email to