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

On Sat, 29 Dec 2012, Marc Balmer wrote:

Am 29.12.2012 um 14:57 schrieb Paul Goyette <>:

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.

(sidebar - any chance you can reconfigure your MUA to properly wrap lines that are being quoted?)

So, to paraphrase,

For modular kernels, you're happy with implicitly loading the lua module whenever the line-discipline module is loaded, and therefore need/want only one variant for the line-discipline module. (Or alternatively, you would be willing to build two separate line-discipline modules, one with lua support and one without, and load the appropriate one.)

For non-modular kernels, you want two variants of the line-discipline code, one which avails itself of lua, and one which does not.

Would it not be sufficient for the line-discipline code to test for the existence of lua at run-time, and select the proper behavior? It should be fairly simple to query for the existence of a lua-specific sysctl(8) variable...

How much additional code would it take to include both variations in a single non-modular kernel?

| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at    |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at |
| Kernel Developer |                          | pgoyette at  |

Home | Main Index | Thread Index | Old Index