[e-lang] Fwd: When will we see a solid capability OS?

Constantine Plotnikov constantine.plotnikov at gmail.com
Sun Jan 20 04:25:21 EST 2008


On Jan 20, 2008 6:03 AM, David Hopwood
<david.hopwood at industrial-designers.co.uk> wrote:
> David Hopwood wrote:
> > Constantine Plotnikov wrote:
> >> IMHO the most acute problem is a good application-level persistence
> >> model (unless I have missed some breakthrough here). Note I do not
> >> think that orthogonal persistence model is sustainable in the long run
> >> (more on that is here:
> >> http://constantine-plotnikov.blogspot.com/2007/02/software-system-longevity-paradigms.html).
> >
> > Support for persistent capabilities does not imply support for orthogonal
> > persistence.
> >
> > Persistent capabilities can be implemented in a filesystem-oriented
> > model, just by splitting each file into data and capability "forks"
> > (the latter acting as an array of capabilities), and adding primitives
> > to get or set the capabilities in a particular subrange of a designated
> > file's capability fork.
>
> Incidentally, this approach can be used to unify files and directories,
> allowing directories to be implemented entirely independently of the
> filesystem (whether or not the latter is in the kernel), possibly with
> multiple specialized implementations.
>
There are a bit more issues-to-be-resolved than you have listed (for
example: removable storage, read-only filesystems, and partial
hardware failures). Also please note that capability OS would need
ability to mount relatively arbitrary services on directory service,
since applications are restricted in rights cannot be expected to
recreate services when needed. And there should be an ability to
create persistent references to services (auto-mount points). There
might be a way to resolve these issues and I even tried to find a
solution to some issues at one of points of time
(http://sourceforge.net/project/showfiles.php?group_id=47959&package_id=104935).

> (A minor complication here is that application writers normally expect
> resolving a path to be a prompt operation, which it isn't necessarily if
> you have to invoke a user-mode directory implementation. But it would be
> no bad thing for application writers to think of resolving a path as a
> blocking, potentially expensive operation, because it is already in the
> presence of network filesystems and symbolic links.)
>
Blocking is not necessary here. Last time I looked, coyotos had
asynchronous syscalls. Mach microkernel also has them AFAIR. IMHO
increased possibilities for failures (including operations that never
complete) will be a bigger problem for application developers than
delay.

Constantine


More information about the e-lang mailing list