LCDproc development and user support list

Text archives Help


[Lcdproc] Re: API-v0.5: drvthis and private_data (comment in CVS)


Chronological Thread 
  • From: joris AT robijn.net (Joris Robijn)
  • Subject: [Lcdproc] Re: API-v0.5: drvthis and private_data (comment in CVS)
  • Date: Wed Dec 5 21:43:01 2001

>
> The pointer to functions are the same for every instance of the driver, they
> are not going to change,
> nor be different per instance. So the only time we need them are in the init
> function.

The pointers to functions have the same value for the different
instances. We need a parameter to access the instance data. If you
look inside C++, you'll see that the first argument on the stack is
also the 'this' pointer.

The drvthis pointer is not needed to call functions from within the
driver, but it's needed to get to the stored data.

Note that the use of the private data struct is necesary for loadable
modules. If you still use globals, and you run two instances of LCDd
both using the same loaded driver, they will use the same global
data! That can give very odd results.

> [who is suppose to alocate the space? (the server) and dealocate? (the
> server)].

The driver, because he's the one handling that data. He then tells
the server that he wants to store the pointer with the
store_private_data_ptr function. He can then read it in the driver
struct. See sed1330.c for an example.

> The only think we need for multiple instance to be possible, is that:
> 1) in init we alocate a private_data, fill-it and return it to the server.
> 2) in every function we receive our (instance) copy of private_data.
> 3) in close we dealocate the private_data.

yes

> In private data we have all the stuff that use to be static (frame_buffer,
> custom char cache, status).
>
> In your document it seem's that the server, prior to calling an instance,
> should call a specific function to put private_data in place.
> I don't see the point of this at all.

It cannot be stored anywhere else. For portability reasons I presume
that it is not possible to _write_ in the data space of another
module. So the driver writes in memory it has allocated itself, and
the server writes in memory it has allocated itself. The driver
should therefor not write the private_data_ptr directly, because it
may not be allowed (I know that it is the case on windows, it appears
to be less tight on Linux).

Hope this clarifies why I proposed it this way...

We could also decide instead to pass the private_data pointer, but
then we first need to get all data out of the driver struct. Should
we do this ?

Joris

--
Joris Robijn
<joris AT robijn.net>
Home: 053 4311 553
Mobile: 06 288 41 964

// To understand recursion, we must first understand recursion




Archive powered by MHonArc 2.6.18.

Top of page