[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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> 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?
>>  https://github.com/dergraf/PacketScript
>>  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!
Main Index |
Thread Index |