LCDproc development and user support list

Text archives Help

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

Chronological Thread 
  • From: David GLAUDE Mailing" <dglaudemailing AT (David GLAUDE Mailing)
  • Subject: [Lcdproc] Re: API-v0.5: drvthis and private_data (comment in CVS)
  • Date: Wed Dec 5 23:51:01 2001

> > 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.
> Ah, David, I see you already commented that in the API document...
As I said in the subject. ;-)

> > 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 ?
> So should we pass the private data pointer directly instead of the
> drvthis pointer ? I would like that too...

Strange, now you seem to agree and on previous e-mail
you were talking about the reason for it.
I am confused now.
Is it because you readed the CVS comment?
What is your last opinion on this???
Could you reply to your previous e-mail?

I need time on this...
Your previous e-mail was talking about a windows DLL issue.
And I forgot (because I don't know them) the limitation of using
loadable library.
Is there somewhere some documentation I could read on
"do and don't" for API that involve loadable library.
I had previous experience with DLL but my problem
were "VB using C issue".

So we should not change our mind too rapidly.
Maybe you were right somehow.
Or I am, or both or noone of us. ;-)

Also I was very confuse by the fact that the config function were
also inside some the structure. Is it because we cannot call
from the "DLL" to the main code???
And that's why we need to establish "callback function"?

What is the quantum leap we try to jump here?
* A good-clean API not MtxOrb minded and hardware
independent where the smart stuff are in the driver
that knows how to do things right?
* A loadable module architecture with on the fly attachement
of new driver
* and dynamic re-read of the config?
(by the way don't we need to tell the driver to re-read the config,
or do you prefere to close and init the driver each time the server
see a change in the config file?)
* An API that permit multiple instances of driver in order to let me
play with the SuperDriver concept?
* An init-less API where driver do bignum/hbar/vbar and cafe?

Or all of them simultaniously???


Archive powered by MHonArc 2.6.18.

Top of page