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.
>>>
>>> The problem with your approach is that such "chicken-and-egg" problems
>>> are to be solved _at_once_ rather than laying "eggs" everywhere around
>>> and have everyone else wait till at least one "chicken" appears.
>>
>> No. I'm talking about put just one egg, just a device driver.
>
> Sorry, but this is not "just one egg". "And counting" was your reaction
> to complaints that almost all the code related to Lua is the code to
> support Lua itself rather than anything else.

"And counting" == there is ongoing work happening outside the tree.

>>>> Sure, we do not *need* a script language interpreter embedded in the
>>>> kernel, as we do not need a specific file system. But I do not get why
>>>> we should not. There is current development of applications being done
>>>> right now. Also, there is a few interesting works that used Lunatik in
>>>> Linux [1, 2] that could be done more easily now in NetBSD just because
>>>> we have the right environment for 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?). I think that is why we *should* (not need)
>>>> have this on the tree. IMHO.
>>>
>>> I have to point out that "interesting work" is commonly used as a sort of
>>> euphemism to refer to highly experimental work with unclear future.
>>
>> Yes. But I'm talking about "interesting *user* work". I'm not claiming
>> that they should be in the kernel. I'm just saying that, IMHO, we
>> should incorporate a small device driver that facilitates this kind of
>> development (outside the tree).
>
> I'm of opinion that this device driver can and should stay outside the tree
> until its utility can be demonstrated without this much strain.
> At last this is one of the reasons why we support kernel modules.

Understand.

>>> You tell that there's "interesting work" using Lua in Linux.
>>> Was it accepted in any experimental Linux distribution like Fedora?
>>> What was the outcome of discussion among linux kernel developers?
>>> Currently there's no indication that it was accepted anywhere.
>>
>> Really don't know. I'm not a member of these communities neither I'm
>> claiming to incorporate such works here. However, I think that there
>> was a discussion about PacketScript on OpenWRT, but I don't know how
>> it evolved.
>
> This demonstrates that Lua isn't actually useful in the kernel.

I don't think so. It could even evince that, but not demonstrate.

>>> And last. The appeal to "why not" is defective. NetBSD is not your
>>> personal playground, there exist other people who have to deal with
>>> the inadvertent mess you can leave after you. That's why you ought
>>> to present solid arguments that justify why other people should tolerate
>>> your experimentations.
>>
>> I guess you misunderstood that. I'm not arguing that we should do it
>> just because there is no contrary argument. I sincerely asked 'why
>> not?' trying to understand the contrary argumentation. Also, I'm not
>> saying that you should tolerate my experimentation. Far away from
>> that. I haven't committed anything nor tried to impose nothing.
>
> On my side it sounded like that, sorry, if I'm wrong.

It could sound as you want, but it wasn't what I meant.

>> I'm
>> just trying to make a  point of view and understand yours. When I
>> talked about experimentation, I was trying to say that providing
>> support for that kind of experimentation for users sounds a good idea
>> for me and I don't see how it is prejudicial. Which doesn't mean that
>> I'm proposing that my personal experimentation should be in tree.
>
> The problem as I see it is that we have one developer (two at most)
> pushing hard for Lua in base and in kernel and providing no satisfactory
> arguments why this is to be done at all. Lack of any real code for years
> reinforces such doubts.
>
> "Why not" sounds as an argument for highly experimental work in this context.
> And I wouldn't have anything against this "why not" if all the work were
> dressed accordingly. For now I'd say that Lua support hasn't demonstrated
> any benefit. I'd say that it should be removed and the work continued
> in a branch until benefits become more clear.

Understand.

Regards,
-- 
Lourival Vieira Neto