-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marcus Brinkmann wrote:
> At Wed, 10 May 2006 08:54:41 -0700, Thomas Bushnell wrote: > >> Still, he is essentially right. The conclusion is--dare I say >> it--right as well. The best computer systems *are* single >> address space systems. Of this, I have absolutely no doubt. > > > But this just replaces the war on the best kernel with a war on the > best memory-safe programming language... which has my consent. hardware-implemented memory protection makes sense -for me- in the old days when the only solution to cope with the related problems was using a dedicated hardware or when you don't want to grant access to certain data to the end-user (which somehow resembles the hardware-implementation-issues related to the current discussions about drm - lemme cite something from my 1995/1996 edition of "Computer Architecture: a quantitative aproach": [about the intel pentium] "Also, the fact that the protection model is a mismatch for the simple paging protection of UNIX means it will be used only by someone writing an operating system especially for this computer. NT from Microsoft is the best candidate, but only time will tell whether the performance cost of such protection is justified fro a personal computer operating system. One wild card is the increasing popularity of the Internet, where virtually any machine can become an information provider, and hence almost anyone could access the desktop computer. This openness leads to extraordinary sharing of information, but it also gives a powerful opportunity for malicious behavior. We conclude this section with questions rather than answers: will the considerable protection engineering effort, which must be borne by each generation of the 80x86 family, be put to good use? Will it prove any safer in practise than its paging system? Will the popularity of the Internet lead to demands of increased support for protection in all computers?" pew ... "lalala ...it's just a little bit of history repeating...") Anyway, leaving these aspects aside, i don't see any reasons to support memory protection in hardware nowadays. you can track all memory accesses in realtime in software, look at the jvm - it works and with an acceptable performance. i think taking care of memory accesses has to be in some way done by the language. the data-structures used in a program can be only known by the language/libraries and therefore the language components know best what accesses are permitted and which ones are not. software-based memory protection is much more flexible, you could easily create non-linear protected memory areas (e.g. a diagonal line on a pixmap). whereas hardware-based memory protection just adds a shitload of problems when you want to share data effectively, especially among multiple processes etc. the problem here is that you have to serialize all data that is shared, that needs specifically and efficiently designed. this is something you don't explicitely need in a SAS-environment. everything can be shared, every component can provide system-wide services. even applications. coming back to the language-issue: today the programming languages and its environments allow a much finer granularity of modularity. looking at i.e. python, you only load and use software components that are *used* and (leaving environment specific details aside) nothing else. so, if linus talks about monolithic-vs-micro-kernel-issue again, he is using arguments that had been valid 15 years ago. the whole component based way of creating general-purpose-software that emerged is totally oppositional to the way machine-oriented software is created. for me the latter looks like a dinosaur that has been tramping around for 35 years, that should pass away, be covered by dust, fossilize and be forgotten. so long... niklas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEZj3Y+k24EnBNzsMRAvSTAJ4tldMC1SeSwgNLvwmreVa0f/MSggCfQG74 8Q1LQJnEuJ/WRh9THzWSClc= =jLom -----END PGP SIGNATURE----- _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
