[Re: [ANNOUNCE] Introducing Codezero]

[email protected] 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




-- 
Bahadir Balban