On Mon, 2006-05-29 at 11:16 +0200, Bas Wijnen wrote: > There is one very important point though. I think those restrictions can > easily be implemented in the user session. This means that we can just build > a system with no support for restricted storage, and add it if we find that we > did need it after all. However, Jonathan doesn't seem to agree. At the > moment I still think he doesn't quite understand what I mean. However, if he > does and is correct that it cannot be added later, we would need to decide > this before building the system. > > So Jonathan, I'm particularly interested in your answer to the question: Do > you agree that restricted storage (in the way I want it, so non-recursive) can > be implemented later, in the user session, or do you still think this is very > hard? If you think it is very hard, why? And related, do you think there is > anything wrong with non-recursive restrictions (so that the process starting a > sub-Hurd can always read and modify any storage inside it), in the sense that > it makes things impossible which should be possible (considering our > objectives)?
Bas: I haven't followed your example closely enough to understand what you mean by "non-recursive", and I don't have time to dig through the archive. I am therefore unable to answer your question about the non-recursive part. For the same reason, I don't have a counter-example and I do not plan to take the time to come up with one. I do not find the entire "private drivers" idea to be motivating. It will be ten years before hardware that can support this in the general cases is available. The special case of writing a user mode driver on top of a generic layer (e.g. SCSI generics, or possibly a similar thing for USB) really isn't a driver at all; it is simply a format converter. Concerning restricted storage: I think it is *impossible* to add later, and I have stated the reason many times already: Removing restricted storage is not simply a minor change in feature set. It is a major change in the entire philosophy of system design. If the initial system incorporates a "translucent storage" assumption, code will be written to assume this, and it will later become impossible to add opaque storage compatibly -- not because it is technically impossible, but because the changes required to fix hidden assumptions will be too large. The reverse is also true: the move to translucency cannot (pragmatically) be done later. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
