[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Deva, as library
From: |
markus kaarn |
Subject: |
Deva, as library |
Date: |
Thu, 20 Jan 2005 17:56:09 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040618 |
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.
If you think of Deva as of a library, not some system service, then Deva
lost it's point here.
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?
If you want Deva to be a library, then i can put "My-Code" name in place
of "Deva"
to Figure 8.1.
What i think, there should be some centralization. Where all
driver-resources registered and
managed.
p.s wasn't from beginning Deva was supposed to be a server?
Thanks,
Markus
- multiple capabilities in a single RPC, Neal H. Walfield, 2005/01/17
- Re: multiple capabilities in a single RPC, Marcus Brinkmann, 2005/01/18
- Re: multiple capabilities in a single RPC, Neal H. Walfield, 2005/01/19
- Deva, as library,
markus kaarn <=
- Re: Deva, as library, Bas Wijnen, 2005/01/20
- Re: Deva, as library, Marcus Brinkmann, 2005/01/21
- Re: Deva, as library, Bas Wijnen, 2005/01/22
- Re: Deva, as library, Marcus Brinkmann, 2005/01/22
- Re: Deva, as library, Bas Wijnen, 2005/01/22