Re: Deva, as library

[Marcus Brinkmann]

At Sat, 22 Jan 2005 17:09:46 +0100,
Bas Wijnen <address@hidden> wrote:
> 
> [1  <text/plain; ISO-8859-1 (7bit)>]
> Marcus Brinkmann wrote:
> >
> > If we say "deva can be a library" we are saying that deva will share
> > its address space with some components of the ddf
> 
> I (and I think Markus, too) thought of deva being linked to callers of
> deva, so a library on the other side of the interface.  That is also not
> impossible, but some things (authentication) need to be shifted to other
> parts of the system then.

Sorry, I have troubles understanding you.  There are basically three issues.

One issue is how things will look from the Hurd side of the system.
From that side, the devices will be accessed via capabilities, which
will be provided by a "server".  A "server" is a thread in some
address space which follows the Hurd RPC/capability protocols.  All
device functions will be invoked via RPCs on capabilities, there is no
exception.

Then there is the issue how things will look from the fabrica side of
the system.  From that side, we want to be Hurd-agnostic.  Basically,
fabrica is interested in some system services (like, allocating
threads or at least thread ids, allocating memory, making privileged
system calls for installing IRQ handlers etc etc).  How should these
interfaces look like?  We don't know the details at this point.  But
there is nothing Hurdish about having memory allocated (although the
way how the memory actually will be allocated can be Hurdish).  Then
fabrica also _provides_ functionality to the system, that's why it
exists.  Like, it allows to open/read/write devices.

How will these interfaces be used/provided?  This is what was under
discussion.

Originally we thought that fabrica will be a stand alone task (or
multiple tasks), exporting and using an RPC interface, and something
that could be called a minimal capability system.  Authentication
would be simple, as certain assumptions can be made (all users are
trusted, the user tasks will be a small constant set, ie, no task
death must be watched out for etc).

But, it is also feasible, and potentially better, at least more
flexible though, to have fabrica use a function call interface only.
Then the function call interface can be filled in with stubs that do
RPCs to other tasks instead (the old design), or they can be directly
filled in with hurdish functionality (the potential new design).

Nothing changes about how the outside, the Hurd system, will see
devices and drivers.  Nothing at all.

What changes is how deva and fabrica communicate with each other and
do the job.

I hope this addresses your question, although I don't know what "a
library on the other side of the interface" means, and why you think
anything needs to be shifted.

I tried to follow the discussion, but frankly, I found it very
confusing.

Thanks,
Marcus