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

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).

>    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).

>    [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.

Regards,
-- 
Lourival Vieira Neto