Session mapping 1:1 vs. 1:n
stefan.kalkowski at ...1...
Thu Aug 27 11:12:22 CEST 2009
On Wednesday, 26. August 2009 18:04:34 Sven Fülster wrote:
> Hi all,
> during my work, I've written a vesa driver which is capable of serving
> multiple clients (using 'virtual' framebuffers, derived from your
> I always thought, that my 'Session_component' is created once when the
> first client opens a connection to my service, so that init calls
> 'create_session' in my 'Root_component' just once and never again.
> That was obviously wrong. I've found out, that 'create_session' is
> called once for each client - not on creation of the connection but on
> the first ipc call the client invokes.
That's not fully true. It is called every time on creation of a new session
for a client (normally, not by the client itself). It is not called when the
client invokes the first IPC. When the client calls the server the first time
the session has to be created already. The outcome of the session creation
process is, that the client owns a capability referencing the service.
Without the capability the client cannot call the server. So a client cannot
call that service before 'create_session' was invoked.
> For my setting, this behaviour is not useful, so I've manually taken
> care of being a singleton by allocating my 'Root_component' only once in
> 'create-session' and handing out that single object subsequently on each
> following session creation.
> I've noticed some strange behaviour with that setting.
> (1) I saw that something complained about my singleton
> [init -> vesa_drv] void
> Genode::Avl_node<NT>::insert(Genode::Avl_node<NT>*) [wit
> h NT = Genode::Object_pool<Genode::Server_object>::Entry]: Inserting
> element 26f
> c twice into avl tree!
When in Genode a node (process) requests a 'session' from its parent, that
request - dependent on your policy - is further propagated until it reaches a
node, which owns a capability to the 'root interface' of the requested
service (base/include/root/root.h). By calling the 'session(arg)' method of
the 'root-interface' one creates a new 'Session_component' - each time it is
called. After the creation process, that component is inserted in an AVL
tree. That tree is used to locate 'Session_component's of the different
clients. So if you implement 'create_session' in a manner, that it will
return the same object twice, you will get the first exception, when the same
object is inserted twice in that tree.
> But that did not seem to matter, so I ignored it...
Well, you shouldn't ignore that :-)
> (2) I had to identify my clients somehow to maintain state information.
> So I hand over a 'shared secret' in each ipc call. That's simply the
> dataspace cap the client got from me.
That's exactly the task of a Session_component - to maintain state information
of the client. The client's capability in fact references a Session_component
and the state encapsulated in that object, so you don't need an extra
identifier or secret.
To your problem: you have to share another common object between
different 'Session_component's of the corresponding clients, if you have to
share something. For example: you might have some framebuffer object
representing the physical framebuffer, that is globally known or referenced
by each Session_component, the Session_component stores all information
needed to handle the clients virtual framebuffer.
That way you don't have to abuse the framework's abstractions either ;-).
Potentially, the documentation of sessions, session components and root
components isn't suffcient. We will review our documents for that.
Also, the vesa framebuffer driver isn't a good starting point for you, as you
want to serve different clients and the driver is limited to one client. You
may have a look at the nitlog service for example, which multiplexes logging
messages of different clients into one buffer (demo/src/server/nitlog).
Moreover, you may have a look at the architectural description of the session
interface once again:
And the introductorily server/client tutorial:
> I noticed that something else than my clients called one of my methods
> during startup with an invalid secret.
> [init -> vesa_drv] virtual void
> ataspace_capability): Framebuffer::Session_component::toggle
> [init -> vesa_drv] virtual void
> ataspace_capability): Framebuffer::Session_component::toggle: _fb_cap
> not accept
> I wonder who might that be. Maybe a relict of mine or does the framework
> some kind of 'reflection'?
It might be a relict or a client, that only speaks the original framebuffer
protocol and not your extended one - but its just guessing.
> (3) However, all that did not really bother, and for a start, everything
> seemed to work nice, but when my setting grew bigger, some ipcs didn't
> work properly.
> One of my two clients (the 2nd) caught an 'Ipc_error' when performing
> its second request. The first request performed fine. I thought that
> maybe the ipc could not be performed because the Session_component was
> serving another ipc at that moment. So I've ignored the exception and i
> kept retrying the ipc call. Without any success, and from here on I
> can't imagine what happens.
You don't get an IPC error because another client uses the same
Session_component, in that case you would simply block.
It's hard to give you a hint in the right direction without knowing the code,
but I recommend, that you first fix the problems above, before searching for
a solution to this one. Potentially it is caused by the former problems.
I have a question too. I wonder why do you write a component to multiplex the
framebuffer, when you have nitpicker, which does this for you. Do you need
some extraordinary functionality?
PS: In general, it is a good idea to abstract things like multiplexing a
driver within a new component and not to build it inside the vesa driver. By
that you could use different framebuffer drivers for your virtual
framebuffer, but potentially now its better not to open up to many building
sites at the same time.
> Does anyone have an idea what I've missed?
> Kind regards
> Sven Fülster
>--- Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day trial. Simplify your report design, integration and deployment - and
> focus on what you do best, core application coding. Discover what's new
> with Crystal Reports now. http://p.sf.net/sfu/bobj-july
> Genode-main mailing list
> Genode-main at lists.sourceforge.net
Genode Labs Developer
More information about the users