[Top][All Lists]

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

Re: Deva, as library

From: Bas Wijnen
Subject: Re: Deva, as library
Date: Thu, 20 Jan 2005 17:47:06 +0100
User-agent: Debian Thunderbird 1.0 (X11/20050116)

markus kaarn wrote:
 From what i've seen on here (address@hidden), there was suggestion
to treat/implement Deva as a library. What i can say here - this is not
Because, even what comes from "Porting Hurd to L4" document by Marcus
Brinkmann Figure 8.1,
the Deva is interface between _all-drivers-space_(PLMs), and the rest of
the system.
So, if you want to implement Deva as library, this means one can access
this "all-drivers-space"
directly, even without using libDeva by writing algorithms in its own code.

Of course there might be some problems with authentication and such,
which don't occur when deva is a server, but that doesn't make it

If you think of Deva as of a library, not some system service, then Deva
lost it's point here.

No, it provides an interface.  Whether that is done by means of a header
file which defines calls using the capability system, or by providing
the function prototypes is quite irrelevant I think.

Think if we have few Plugin Managers, and i start my program, which uses
some device.
How can i find device i need? How can i at least find these Plugin

You don't have to worry about it, deva will find it.  How it will do it
does not matter.  Libc is a library, it does lots of things which are
platform-specific, and you don't want to care about.  Think of DNS
lookups for example.  They may not be too platform-specific, but you
definitely don't want to care about them.

If you want Deva to be a library, then i can put "My-Code" name in place
of "Deva"
to Figure 8.1.

You can, indeed.  You can write your own code instead of libc as well.
The result will break when any internal interface changes (which of
course happens simultaneously in libc and whatever is interfaced), but
you can use your own code instead of libc.

What i think, there should be some centralization. Where all
driver-resources registered and

This can be done in a file.  An environment variable could hold the
location of the file.  It can be done with some dark magic of which only
the deva library and libc know how it works.  It doesn't really matter
how it's done, as long as it works.  And it _can_ work if deva is a
library.  I think the biggest downside of it is that the drivers will
then have to do authentications themselves (actually the plugin manager,
not the drivers), so you might want to have a deva-client library.  Then
again, that's not impossible either. :-)

p.s wasn't from beginning Deva was supposed to be a server?

Indeed it was, but ideas change.  At the moment, deva isn't supposed to
be a library, but it is a possibility.  It is also still possible that
it will be a server.


I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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