Re: [Fwd: Re: Deva interface]

[R. Koot]

markus kaarn wrote:
> Marcus Brinkmann wrote:
>  >
>  >  Does anybody else see other problems with making Deva a library?
>  >
>
> If you define Deva as a library, what do you profit ?
> Deva, as server, can serve at least as place for registering
> device drivers. If client needs to access a device, he goes
> for Deva and asks, if there is one he needs.
>
> There is still, must be a place to keep device-list register.
> If Deva will not serve as one. Another place will be created.
> Do we really must dual the work?

On any micro-kernel based OS you will need some kind of Name Service to 
find other services. (Task will do this in HURD, correct me if I'm 
wrong). This service can also manage the "device list". So you by not 
letting Deva do it you actually avoiding double work. Another way to 
find devices if by querying the root driver which will return a list of 
bus drivers wich in turn return a list of device drivers.

> If every time, i start my program and Deva-library with it. LibDeva will
> have to lookup though the system-services(whatever) to find device-drivers
> or plugin-managers to be used by my program. This will result in more
> code execution.

Looking up a device in the nameserver will be just as slow as lokking it 
up in a "Deva-server". And the servers that access drivers directly will 
be servers that are started once during boot, because they are the 
servers that abstract devices into more useable things (think a 
windowing system, LVM, audio service, ... )

> On other hand, there will still be work involved between deva and ddf,
> and proper interfaces between them (as i know) have to be worked out.
>
> We must see both cases in action, so can compare? %')

I'm seeing Deva as a collection of servers, libraries adn protocols. Now 
if you can logically deduce that the operations performed by this is a 
subset of the operations performed by "Deva as a server" you will be 
certain it will perform equal of better in the real world, so you don't 
need a proof-of-concept for both.


Ruud