LCDproc development and user support list

Text archives Help

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

Chronological Thread 
  • From: joris AT (Joris Robijn)
  • Subject: [Lcdproc] GPL and loadable module + Re: Re: API-v0.5: drvthis and private_data (comment in CVS)
  • Date: Thu Dec 6 14:36:01 2001

On 6 Dec 2001, at 14:55, David GLAUDE Mailing wrote:

> 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!!!]

Yes it should be. I'll check that it's on top of my files.

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

I guess this is a problem with all software that is breakable in
parts. Currently a non-GPL program can write to the socket too...

If you ask me, we should never 'deal' with non-GPL code. If they want
to connect to socket, or load a module they wrote, fine, but don't
expect us to help them. Because if we can never benefit from it, it
does not help open source.

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

Yes we need to check what the license says. You will check ?

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

Well the cast is still needed. Then you get extra code like:

void clear(p2) {
p = (cast) p2;

So still some code remains at the top of the function.

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

Np, the private thing is a pointer in the driver struct. You can make
the call like:
driver->clear( driver->private_data_ptr );
instead of:
driver->clear( driver );
Does not really differ.

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

Yes. That makes things more complex I think.
Currently there is a driver structure for every _instance_ of a
driver. It makes things more complex if we do the driver struct per
physical driver and the private data per instance.

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

Well, we can think about it. It looks a lot alike. Later...

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

OK I'll keep the call backs.

> And what about the debug/report code.
> Is that part of the function we need in the list of stuff we callback for.

To remain consistent it should use callback too then. However, to
optimize the debug() calls away when DEBUG is not defined, some extra
stuff is needed. No problem on itself.

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

Only core.

> Who call what function when in drvthis.

Anything can call anything. But why would a driver call a driver
function or the core call a callback function...

> Yes, we want it all and working.

'Working' will be the hardest part ;)

> Yes, version number.
> Same problem with DLL, no way to know the param,
> just the name of the entry point!!!

After all these thoughts I start to get the conviction that we can
better leave the currect drvthis thing intact. The name parameter can
then simply stay in the structure, as it should because the server
needs it too.

We're starting to get nice subject lines :)


Joris Robijn
<joris AT>
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