l4-hurd
[Top][All Lists]
Advanced

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

Re: drivers for l4 (2)


From: Daniel Wagner
Subject: Re: drivers for l4 (2)
Date: Mon, 24 Mar 2003 22:21:16 +0100
User-agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/21.2

Maurizio Boriani <address@hidden> writes:

> I think all DDE could be well designed and implemented using OOP 

Yes, I think the driver framework should be in a OO design.  Using C++
is for me also fine.  You have to convince the others :)

> L4, pistachio should be implemented using c++). 

IRC, pistachio is written in C++.

Also, because

>     Daniel>   How to install a interrupt handler: Precondition(s): 
> [...]
> the above should be the basic IRQ handling on L4, right?

Yes.

> As said above, a base class bus manager could have inherited classes which 
> implement extended interfaces for a particular type of bus. 

That's exactly what we have proposed.  

>     Daniel> + Bootup: 
>     Daniel>   + All drivers are loaded in their own address
>     Daniel>     space for now 
>
> as shared object

What we had in mind was that a specif driver implements a certain
interface.  If the driver wants to accesss resources, it would ask the
bus driver for the resource.  The driver and the bus driver would talk
to each other over IPC.  So their is no need to run them in the same
address space.  That's why we said all drivers can run in their onw
address space at the beginning.  Of course there are some drivers
which have to share the same address space.  For example if there are
more then one bus driver, e.g. the root bus driver and the PCI bus
driver, they are bound to use the same address space.

>         http://www.cs.wustl.edu/~schmidt/PDF/Svc-Conf.pdf
>         http://www.cs.wustl.edu/~schmidt/PDF/IWCDS-94.pdf
>         http://www.cs.wustl.edu/~schmidt/PDF/C++-world-93.pdf
>
> Obviously the above describe particularly ACE framework but the generic idea
> and design could be used in DDE context.

Thanks for the tip.  I'm reading these papers.

> I think hotplug could be skipped out make reading directly config file to 
> root bus manager and making it starting out threads as needing.

The idea behind the hotplug server is that we didn't wanted to have
the bus manager overloaded with things.  But of course you could argue
that's the job of the root bus manager.  Maybe Peter can tell more
about the advantage  of having hotplug, since it was his ideas.

> couldn't be rmgr the root bus manager? 

Hmm, I don't like this idea since rmgr already does a lot of things.
Bundling all in rmgr seems for me not a good idea. 

>     Daniel>   + In which address space is the resource manager started?  
>
>  user space I think. And get initial resources by sigma0

Aehmm, obviously I shouldn't write things down 3 o'clock in the morning :)

> as said above if rmgr is the "root bus manager" there isn't need of
> threads migration

Yes that's true.  Good point.

>     Daniel> TODO :
> [...]
> a well designed hierarchy of classes :)

Definitively!

> Now I'm working on port UVM to L4 and I think this could be finished in next
> 3 months. Next I'll apply full time in DDE (in coworking with you
> all :) )

Good to hear.

daniel




reply via email to

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