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

[Aleksej Saushev <asau%inbox.ru@localhost>]

  Hello,

Lourival Vieira Neto <lourival.neto%gmail.com@localhost> writes:

> On Fri, Oct 18, 2013 at 9:08 AM, Taylor R Campbell 
> <riastradh%netbsd.org@localhost> wrote:
>>    Date: Thu, 17 Oct 2013 19:16:16 -0300
>>    From: 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.

>>    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?

>>    [1] https://github.com/dergraf/PacketScript
>>    [2] http://www.pdsw.org/pdsw12/papers/grawinkle-pdsw12.pdf
>>
>> In the two links you gave, I found precisely five lines of Lua code,
>> buried in the paper, and those five lines seemed to exist only for the
>> purpose of measuring how much overhead Lua adds to the existing pNFS
>> code or something.
>
> I'm just showing examples of how it could be useful for user
> applications. I understand that you do not agree with that. But I'm
> not arguing that we have to add these applications into the tree. I'm
> arguing that we could benefit users with such a tool.

The problem is that the number of such users is negligible and all of them
are developers that are able to build their kernel module outside the tree.


-- 
BCE HA MOPE!