tech-kern archive

[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 <> writes:

> On Thu, Oct 17, 2013 at 1:26 PM, Jeff Rizzo <> 
> wrote:
>> On 10/14/13 1:46 PM, Marc Balmer wrote:
>>> There is real word, real working code.  In userland and in kernel space.
>>>   There are developers waiting for the kernel parts to be committet, so
>>> they can continue their work as well.
>> *Where* is this code?  The pattern I see happening over and over again is:
>> NetBSD Community: "Please show us the real working code that needs this"
>> mbalmer:  "the code is there!" (pointer to actual code not in evidence)
>> I do not doubt that something exists, but the onus is on the person
>> proposing the import to convince the skeptics, or at least to make an actual
>> effort.  I see lots of handwaving, and little actual code.  YEARS after the
>> import of lua into the main tree, I see very little in-tree evidence of its
>> use.
>> In fact, what I see is limited to :
>> 1) evidence of lua bindings for netpgp.
>> 2) evidence of some tests in external/bsd/lutok
>> 3) the actual lua arc in external/mit/lua
>> 4) gpio and sqlite stuff in liblua
>> 5) some lua bindings in libexec/httpd ("bozohttpd")
>> 6) two example files in share/examples/lua
>> 7) the luactl/lua module/lua(4) stuff you imported yesterday
> ...and counting. There is also ongoing working happening =).

As Jeff points what is counting is support code.

>> Am I missing something major here?  The only actual usage I see is netpgp
>> and httpd;  the rest is all in support of lua itself.  I do not see evidence
>> that anyone is actually using lua in such a way that requires it in-tree.
>> When you originally proposed importing lua back in 2010, you talked a lot
>> about how uses would materialize.  It's now been 3 years, and I just don't
>> see them.  If I am wrong about this, I would love some solid pointers to
>> evidence of my wrongness.
>> Now you're using very similar arguments for bringing lua into the kernel;  I
>> would very much like to see some real, practical, *useful* code
>> demonstrating just why this is a good thing.  Beyond the 'gee, whiz' factor,
>> I just don't see it.
> 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.

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

I doubt very much that we want such unreliable development practices
like "agile" ones in the kernel, and experimentation work can be done
easier and better in a branch or a personal repository.

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.


Home | Main Index | Thread Index | Old Index