[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: lua(4), non-invasive and invasive parts
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:
/* do Lua stuff */
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?
Main Index |
Thread Index |