Hi, On Tue, Apr 01, 2008 at 07:39:07PM +0200, zhengda wrote:
> There are two choices for me: to improve subhurds and to create a new > subenvironments. OK. > In my understanding, Hurd is a set of servers which provide the > services provided by the monolithic kernel before such as file > system, networking and etc. These servers run as normal processes on > a microkernel such as Mach or L4, whose responsibility is to help > servers communicate with each other. Because of this architecture, it > is possible for us to run duplicate servers. Indeed. > If we run another full set of servers, we can get another Hurd on our > machine. This is my understanding of how subhurd works. Correct :-) > But currently there are no communication channels between the subhurd > and the main one, and no mechanism for safe sharing of hardware > devices. This could be the task of the project. I see. So that would exactly match the "improve subhurds" subtask. > In the other hand, if we can run some duplicate servers, we can get a > smaller subenvirnoment which lives within the main system and uses > most of its facilities. The advantage is that we can get a virtual > subenvironment but save a lot of resources on the computer. It's not only about saving resources. A subhurd needs an own partition, a complete bootup, and runs totally isolated from the main system instance. That can be very useful properties in some cases (similar to some traditional virtualization solutions); but the administrative burden, the slow startup, and the lack of easy interaction make them totally unsuitable in some other situations -- even when ignoring resource usage... > The virtual network I mentioned above is actually a network simulator. > Its work is to simulate a network in the operating system, so > different processes in the operating system think they are running on > different IPs. That sounds like a pretty interesting use case :-) > In Hurd, we can run one server of networking for one IP. It should be > easy to be done in Hurd. It is basically possible already (and used for subhurds); but as you observed correctly, it requires some additional mechanisms to make it suitable for what you want to do. > Then we have to provide a mechanism to allow the process to choose > which server to use, That matches another project idea: "Server Overriding Mechanism". It is indeed closely related to the subenvironments idea; I already considered merging them... > and provide a mechanism to allow servers communicate with each other. Right. Presently it's possible to run multiple network stacks in parallel on the same network device (in subhurds for example), and each one can make and receive connections under it's own IP (thanks to the packet filter in Mach) -- so they appear like multiple individual hosts on the network. But unlike with true hosts, it's not possible for them to communicate among each other... This is actually a feature I'm missing myself :-) This doesn't exactly match the subenvironments subtask. (It actually leans a bit towards the subhurd task... This shows that the subtasks are actually closely related and can't be clearly separated.) However, it definitely falls within the hurdish virtualization task :-) I know that it's hard for someone new to this stuff: but could you try to investigate this a bit and make some proposal(s) how it could be implemented?... -antrik-
