[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Re: [ANNOUNCE] Introducing Codezero]

From: Bahadir Balban
Subject: [Re: [ANNOUNCE] Introducing Codezero]
Date: Mon, 13 Jul 2009 15:53:52 +0300
User-agent: Thunderbird (X11/20090608)

address@hidden wrote:
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:

- 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

  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!

Obviously in a microkernel system, to provide the file-io interface
certain core servers are not going to have this interface. I always
meant file-io is only to be provided by services that are attached to
the process namespace. But inside the namespace, file-io should be used
as much as possible, instead of object-specific methods on every and
each path component.

  > - The Hurd is UNIX (POSIX) compatible

- 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.)

Could you please describe the sequence of events on how you could
implement a POSIX system call using a decentralized model? (And perhaps
the flexibility aspect of it)

In my current (non-capability) implementation for example, here's what


1.) IPC to VFS service FS0, given the pathname, flags, mode args.
2.) FS0 checks the given validity of the path (single namespace)
3.) FS0 finds the right file, checks permissions, returns the file

Here, if file-based services were implemented, it would do the following:
2.) Check each path component for an fs-mount.
3.) Check permissions, call relevant service with that component for an
4.) Return service id and new fd
5.) User program then calls that service for further requests (i.e. with
the fd, calling read, write etc.)

In this model, FS0 takes the role of path navigation + authorization of
each path component.

In a decentralized model, how would you traverse each path component?
Dividing duties into well-defined servers makes sense to me.

- 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.


By limits I didn't mean fixed limits. I generally try not to design
things using fixed limits. But you certainly should have limits to
resources. These can dynamically change.

In Linux, there are limits to how much while(1) fork(); you can do,
which is useful for obvious reasons. Those limits can be changed by
system calls.

I think the question is how elegantly can you manage and dynamically
change such limits. It seems this can be done using capabilities, and I
don't think L4 is such a bad candidate for implementing them.


Bahadir Balban

Bahadir Balban

reply via email to

[Prev in Thread] Current Thread [Next in Thread]