[okl4-developer] V2 device_create functions

[Nelson Tam]

Hi Ryan,

On 10/04/2008, at 10:01 AM, Ryan Heffernan wrote:
>
> I've been writing an Iguana driver using the v2 framework and trying  
> to
> keep my code as close as possible to that of the other iguana drivers
> (vserial, vtimer, etc), but yesterday I noticed something that seemed
> odd with the existing drivers and wondered if someone could clear this
> up.
>
> The device_create functions in the driver servers (ie.
> vserial/src/serial_server.c) all return a cap_t with references to the
> created device. I assume this is so that if needed, shared memory  
> can be
> set up between a client and the driver server (ie. for a shared  
> buffer),
> since a client can call devicecore to get this object reference and
> recreate the device's cap_t on the client side to initiate the shared
> memory.

If I understood your question correctly, then I think the caveat lies  
here.  The cap_t that is returned by device_create() will not help the  
client and server set up shared memory.

What you really want to do is something similar to  
virtual_serial_add_memsection_impl().  	The idea is, if the client  
wants to set up shared memory with the server, the memory resource  
should be accounted towards the client, not the server.

So the client should do a memsection_create(), then call  
virtual_serial_add_memsection().  The server will then add it to its  
cap list and the shared memsection is now set up.  You can adopt the  
same method for the driver you're writing.

See iguana/example/drivers/src/drivers_example.c:init_serial() for an  
example of this.

> However, what is actually stored in the cap_t returned by  
> device_create
> is a pointer to the base address of the device structure (from a  
> malloc
> call), not a memory section reference like memsection_create() would
> return. From what i gather, it's this memory reference
> (memsection_ref_t) that needs to be stored in a cap for proper shared
> memory to be set up, and indeed I wasn't able to set up shared memory
> between a client and my driver server with the device_create  
> function in
> its current incarnation. When I changed the device_create function  
> in my
> driver to use memsection create I was then able to create some shared
> memory using the objref_t returned by devicecore_get_vdevice.
>
> My first question is if it appears that I did something wrong in  
> trying
> to set up shared memory with the original device_create that used
> malloc. I did something like this:
>
> cap_t cap;
>
> ...stuff to setup devicecore...
>
> objref_t obj = device_core_get_vdevice(..)
> cap.ref.obj = obj;
> cap.passwd = 0; //My driver server's cap also had password 0
> clist_insert(clist_default, cap);
> //Any attempts now to dereference obj cause a pagefault

So yeah, this wouldn't work as explained above.

> My second question is why malloc is used in device_create instead of
> memsection_create, and why it doesn't return a cap that contains a
> memsection_ref_t?
>
> Thanks for the help! If I I'm not clear enough in my attempts to  
> explain
> my issue please let me know and I'll try to make it more clear.

The struct serial_device within serial_server.c is basically used to  
keep track of the per-client state within the server.  It's not  
intended to be shared with clients, and since the number of clients is  
not known in advance, malloc() is used to allocate each struct instance.

memsections aren't appropriate because they are at least 1 page in  
size; and there's no point using them if the struct isn't meant to be  
shared.

You'll notice however that the cap returned by device_create() is  
still used by the client to identify themselves to the server.

--
(nt)

Nelson Tam

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1560 bytes
Desc: not available
Url : http://lists.okl4.org/pipermail/developer/attachments/20080415/a9a0c316/attachment.bin