Re: Why do we need lua in-tree again? Yet another call for actual evidence, please. (was Re: Moving Lua source codes)

[Lourival Vieira Neto <lourival.neto%gmail.com@localhost>]

>>>    Lua is a tool, not an end in itself. I think that you are formulating
>>>    a chicken-and-egg problem: we need the basic support for then having
>>>    applications, and we need applications for then having basic support.
>>>
>>> This is not a chicken-and-egg problem.  You can make an experimental
>>> kernel with Lua support and make an experimental application in Lua,
>>> all before anything has to be committed to HEAD[*].  Then you can show
>>> that the application serves a useful function, has compelling benefits
>>> over writing it in C, and can offer confidence in robustness.
>>>
>>> [*] You could do this in a branch, you could do this in a private Git
>>> repository, or you could even just do this in a local CVS checkout
>>> (since kernel Lua requires no invasive changes, right?).
>>
>> Yes, but how do we do device driver development? We are branching the
>> tree for each non-intrusive and disabled-by-default device driver? If
>> we have developed a device driver for an uncommon device, we have to
>> put it in a branch? (Please, note I'm friendly asking that).
>
> We didn't import yet another programming language interpreter for driver
> development previously. Besides, what are drivers developed in Lua so far?
> If I understand it correctly, the only driver is the Lua interpreter itself.

I meant traditional device driver, but never mind.

>>>    That is not about needing, but it is about supporting a certain
>>>    kind of agile development, prototyping, customization and
>>>    experimentation in the NetBSD kernel (how could it be hurtful?).
>>>
>>> Prototyping and experimentation is great!  Show examples!  What hurts
>>> is getting bitrotten code that nobody actually maintains or uses (when
>>> was the last Lua update in src?) and provides a new Turing machine
>>> with device access in the kernel for attack vectors.
>>
>> I don't see how an optional module could be used for attacks. If users
>> enable that, they should know what they are doing (such as loading a
>> kernel module).
>
> Was anything done to warn users?

The code is not linked yet.

Regards,
-- 
Lourival Vieira Neto