Re: lua(4), non-invasive and invasive parts

[Marc Balmer <marc%msys.ch@localhost>]

Am 29.12.2012 um 12:47 schrieb matthew green <mrg%eterna.com.au@localhost>:

> 
>>     Which is fine for gpiosim, as it can just depend on the lua
>> module.  For LINEDISC_LUA, there would have to be some kind of hook to
>> which the lua module would attach when loaded, so that the kernel would
>> still function even without the module loaded.
> 
> since this means i can't use gpiosim without LUA being
> available, it seems a poor choice.  ie, don't force me
> to enable an experimental scripts-in-kernel when i want
> to use something that does not depend on it.

That is exactly the concern I am trying to solve with my idea of 'options LUA'. 
 Maybe the problem needs to be adressed from two sides:

- Use 'options LUA' for statically linked kernels
- Use the module dependencies for modular kernels.

In the gpiosim(4) code I could then use the following hack:

#ifdef _MODULE
#define LUA
#endif

...

#ifdef LUA
   /* do Lua stuff */
#endif

So this would mean that gpiosim(4) built as module always has Lua, gpiosim(4) 
build as part of a static kernel only has Lua when the kernel option is set.

(It is really no ideal that we have static kernels and modular kernels that 
are/can be configured in different and non-compatible ways).

> 
> is there a way to structure the code such that there
> are more modules (whether modloaded or statically
> linked) such that:
> 
>   gpiosim_lua: gpiosim lua

Did you mean having two gpiosim modules, one with and one without Lua?