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: Thu Dec 6 01:44:02 2001

OK now my requested reply to my own mail.

On 5 Dec 2001, at 22:45, Joris Robijn wrote:

> >
> > 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.

Well, 'needed'... there can be other ways to get to the private data,
like the direct pointer to it. This should be a void*, because the
core does not know the drivers private data structure (black box).
BTW the private_data_ptr in the driver struct is a void* too.

> 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...

I don't directly see anything else to reply to. Is the above clear ?

> 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 ?

Yes, well, we just have two options I guess. One is already partly
implemented.

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