Re: [ANNOUNCE] Introducing Codezero: msg#00014 l4-hurd-gnu

olafBuddenhagen@xxxxxxx 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
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!

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
happens:

Open:

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

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

-antrik-

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.

Thanks,

--
Bahadir Balban