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