Hi, On Thu, Jul 02, 2009 at 09:20:31PM +0300, Bahadir Balban wrote: > Bas Wijnen wrote:
> I have taken a closer look at the existing Hurd implementation. It > looks very much like what I had in mind when meaning "microkernel > based OS using plan 9 design principles". Not really. There *are* some similarities regarding the file system handling -- but there are also very fundamental differences between Plan 9 and the Hurd, thich go far beyond monolithic vs. microkernel design: - The Hurd is UNIX (POSIX) compatible - While (almost) all services are attached to the file system tree, not all services actually export a file system interface! Personally, I advocate using FS-based interfaces as much as possible. Yet, there are some cases where they get very arward and/or inefficient, and domain-specific interfaces simply make a lot more sense. Also, some Hurd services are indeed used to implement the file systems in the first place -- they work *below* the FS level, and obviously can't use an FS interface! - File systems are completely decentralized -- clients always talk to the FS servers directly, without any central VFS layer. (I don't think that's the case in Plan 9?) This offers much more flexibility -- the way the FS interfaces themselfs work can be modified. Many things can be implemented as normal translators, that would require special VFS support on other systems. (Extended attributes, VFS-based union mounts, local namespaces, firmlink, magic file name suffixes etc.) - The system design allows users and applications to change almost all aspects of the system functionality in the local environment easily and without affecting other parts of the system. (This is possible with Plan 9 to some extent; but the Hurd allows it at a much lower level -- including stuff like the filesystem interfaces, access control mechanisms, program execution and process management, and so on.) I hope I didn't forget any major differences... > Essentially a Hurd translator setup with settrans is what a file-based > server does when mounted in Plan 9. Yes, aside from the differences listed above... >> I don't have enough idea about the code to know how good that would >> work. Does your kernel use dynamic memory itself, by the way? In >> other words, can the kernel get out-of-memory errors? > > Currently, we do have this. There is a very rigorous memory allocation > policy though. Page tables, thread control blocks and space structures > are allocated which are only related to thread and address space > creation. These can be easily controlled by introducing limits or > capabilities on thread and address space creation. We don't really want this kind of fixed limits in a general-purpose system... This is actually one of the major concerns behind all the design work regarding new Hurd implementations. -antrik-
