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:38:01 2001

> > Ah, David, I see you already commented that in the API document...
> As I said in the subject. ;-)
Yes sorry.

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

Well, you mention a lot of things now, so I _do_ reply to this one
too.

I guess I just started to change my mind a bit because you had a good
point :) It should not need to make a difference what kind of pointer
we give, on the condition that we remove all driver data from the
driver struct.

Currently it is like this (sed1330 already does this):

typedef struct driversprivatedatastruct {
int width, height;
char * framebuf;
} driversprivatedatastruct;

int init(drvthis, bla) {
p = (cast) malloc( sizeof( driversprivatedatastruct ) );
store_private_data_ptr( (cast) p );
p->width = 20;
p->height = 4;
// Allocate a FB
p->framebuf = malloc( p->width * p->height );
// init the driver etc.
return 0;
}

void clear(drvthis) {
p = (cast) (drvthis->private_data);
// do things, in this case clear the framebuffer
memset( p->framebuf, ' ', p->width * p->height );
}


But we could do it like this:

typedef struct driversprivatedatastruct {
Driver * driver;
int width, height;
char * framebuf;
} driversprivatedatastruct;

int init(drvthis, bla) {
p = malloc( sizeof( driversprivatedatastruct ) );
store_private_data_ptr( p );
p->width = 20;
p->height = 4;
// Allocate a FB
p->framebuf = malloc( p->width * p->height );
// Store driver struct pointer
p->driver = drvthis;
// init the driver etc.
return 0;
}

void clear(p) { // <--- how to cast this p ?
// do things, in this case clear the framebuffer
memset( p->framebuf, ' ', p->width * p->height );
}

In this example I did store the Driver * in the struct. Maybe it is
not needed. One problem is that it is necesary to tell the driver
what name he has got. (a.o. for the reading of the correct config
file section that we spoke about lately).

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

I've been looking for it myself too, but couldn't find it. I've been
working with Delphi in windows some years ago. I remember that you
could not _write_ in the segments of an other module. Linux appears
to allow it, but I don't know if all OSes do. Anyway, we don't _need_
to write in the others data segment, we can avoid it easily.

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

I started to wonder if that was necesary. Not because the callback is
not possible, that should be possible anyway. But more because I was
affraid that under window the symbols should not be locateable in the
LCDD.EXE from the loaded module. Right now, I think the symbols _are_
locateable, even under windows. *nux does that dyn.linking
automagically, maybe windows too. So I think we can remove the
config_* and store_private_ptr from the driver struct. (we can always
add them again if there are accessability problems)

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

Why not all at once. I think it's possible. If we change the API
anyway, let it be a good change. We can build on that for a long
time.

Once there are loadable drivers, changing the API is harder, because
then the API version needs to be increased every time. That is
because (if I'm correct) you cannot run-time check the exact function
arguments that a function in an other (alien) modules requires.
Because the dlsym function only returns a void*, the programmer
should cast that void* to what he needs and therefor already know
what arguments he should supply to the function. If there is a
unnoticed version mismatch between a driver and LCDd things can go
wrong. The only check is a version number.

Now I'm gonna sleep, but sorry I have not got the diff ready... Well
we needed more considerations anyway.

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