tech-kern archive
[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 14:57 schrieb Paul Goyette <paul%whooppee.com@localhost>:
> On Sat, 29 Dec 2012, Marc Balmer wrote:
>
>>> this is going to upset dyoung i'm sure :) but it seems to me that
>>> if these invasive changes to individual subsystems are needed like
>>> this, and we want them to be optional, then imo they should be on
>>> a per-subsystem basis, not global. eg something like:
>>>
>>> options LINEDISC_LUA
>>> options GPIOSIM_LUA
>>>
>>> etc. the ugliness could/should be largely hidden in header files.
>>
>> The problem remains that modules no nothing about kernel options. Maybe - in
>> an ideal world - there should be no kernel options at all, but only
>> modules... ;)
>
> Perhaps I'm missing something obvious, but why can you not have your
> line-discipline module simply depend on a lua module? Then you no longer
> need to know if the kernel "has lua" because it can always "get lua when it
> needs it".
Yes absolutely. As long as we talk "modules-only", there is no problem.
The problem I was trying to solve (and which is probably not solvable in a
proper manner) is for statically linked kernels. As long as drivers like e.g.
gpiosim(4) can be compiled as module _and_ as part of a static kernel, the
issue remains.
So to restate what I mentioned earlier:
- For modules, the problem does not really exist, since they can "get Lua when
they need it", as you mentioned above
- For static kernels, an 'options LUA' could be used.
Home |
Main Index |
Thread Index |
Old Index