Re: Deva, as library

[Bas Wijnen]

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
> serious.
> 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
impossible.

> 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
> Managers?

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

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.

Thanks,
Bas

--
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 http://129.125.47.90/e-mail.html

signature.asc
Description: OpenPGP digital signature