LCDproc development and user support list

Text archives Help


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


Chronological Thread 
  • From: David GLAUDE Mailing" <dglaudemailing AT gmx.net (David GLAUDE Mailing)
  • Subject: GPL and loadable module + Re: [Lcdproc] Re: API-v0.5: drvthis and private_data (comment in CVS)
  • Date: Thu Dec 6 13:54:02 2001

GPL first as it might be very important...
We are going to introduce loadable module in lcdproc API v0.5.
1) This mean from a technical point of view that other program could use our
module for displaying on LCD.
2) Also from a technical point of view it also mean that someone could write
a module without giving the code for it.

AFAIK our little project is GNU GPL licenced. [it should be put on top of
every file!!!]

So (1) and (2) are linking GPL to potentially non-GPL code.
We need to know what the GPL say about this and what we want about this.
I know this is a potential loophole in the GPL and at least Linux kernel is
having an issue with this.
Linus choose to accept non-GPL module to supporte closed module.
And RMS is not happy about this at all.

Most of us are Linux user, a few Solaris and some FreeBSD (and they complain
about portability).
This might mean we have peaple with 3 differents mindset, free/closed/open.
;-)
But we are here on the same project and need to know what is possible (from
a licence point of view)
and what we really want.

I need main developper input on this issue.
It is a VERY important issue for me.
I personnaly don't wan't a closed application to benefit from my free work.
If they want to use part of my work on MtxOrb driver, they can talk the
protocol
and connect to LCDd accross the network.

David GLAUDE


> 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.
Agree, all data should be access via function (to set or get, mostly get for
us).

If it does not matter if we give drvthis in every call or
if we give private_data for every call... then we need to find
rationale for choosing one or the other.

I think we need to check:
1) What is easyer from the driver code point of view.

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

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

2) What is easyer from server point of view.
As far as I remember, in the server code, there is a Linked List
that hold a pointer per driver (could be instance).
Now if this list still exist and is design for one pointer,
you may want to keep your solution because it is easyer
from the server point of view.

3) What is best from a memory point of view...
If we have the current solution, then for each driver we need to
alocate a copy of drvthis with all the pointer to variable.
With the other solution (and a usage count) we can alocate
only once the drvthis and multiple separate private_data.

> 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).
Maybe that should be done in the init call only.
If it is require to remember that, it is up to the driver to save
a copy of that information in private_data.

4) What other benefit we could have from one solution or the other...
Maybe your current solution, we are more C++ like and we could have
a driver derived from another driver.
I mean a driver enhancing another one by adding extra function to it.
If we are really very C++ like, then maybe one day we will migrate
the driver API into a class API. ;-)

> 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)
If we keep them it is maybe more flexible.
Anything could use our driver module and provide compatible config function
whatever the name they already use. It might be better.
So currently I like the call back stuff...
And what about the debug/report code.
Is that part of the function we need in the list of stuff we callback for.

Just it should be very well documented who set what part of drvthis.
Who alocate what in drvthis.
Who call what function when in drvthis.

> > 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.
Yes, we want it all and working.

> 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.
Yes, version number.
Same problem with DLL, no way to know the param,
just the name of the entry point!!!






Archive powered by MHonArc 2.6.18.

Top of page