On Fri, 2007-01-12 at 20:23 +0100, Marcus Brinkmann wrote: > This is an example were "transparent access" to the storage not just > means inspectability, but intimate knowledge about its structure. If > you want to leverage the flexibility illustrated by the above > examples. the algorithms to make use of this must be standardized and > exist outside of the bundle itself.
> If that is a goal, then it seems not to make much sense to have the > algorithms twice, once in the bundle and once outside. This is complete nonsense. The algorithm for strlen() is well known. It still makes sense to have it in a common place: libc. In the same way, the constructor algorithm is well known and can be reproduced by anyone. In the presence of translucency, there is still an argument for a constructor: things that run in separate processes are less failure-prone than things that run in libraries. The great weakness of libraries is that they share address spaces with their host application. This makes each vulnerable to flaws in the other. Purely from an engineering perspective, it is sensible to make the functionality of each process as small as it can be made while still achieving acceptable performance. Libraries are a tool that you should only reach for when the performance cost of engineerability becomes prohibitive. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
