[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netbsd-tech-kern
Subject:    Re: [patch] put Lua standard libraries into the kernel
From:       Justin Cormack <justin () specialbusservice ! com>
Date:       2013-11-29 15:45:49
Message-ID: CAK4o1WyuR=TaUu16NxC8K+3r9hVn4-Oa1J69chW1PxwjXANeWA () mail ! gmail ! com
[Download RAW message or body]

On 29 Nov 2013 14:11, "Lourival Vieira Neto" <lourival.neto@gmail.com>
wrote:
>
> On Fri, Nov 29, 2013 at 10:03 AM, Marc Balmer <marc@msys.ch> wrote:
> > Am 29.11.13 12:38, schrieb Lourival Vieira Neto:
> >>> It will be interesting to see by how much memory the addition of the
> >>> standard libraries will grow lua(4).  lneto claims it does not grow at
> >>> all.  If it should, we can still move the standard libraries to a
kmod.
> >>
> >> I just double checked now (using nm to confirm). In fact, I was
> >> commenting the wrong portion of the Makefile to test. Sorry about that
> >> =(. Here is the result in amd64: 240K with stdlibs and auxlib, 166K
> >> with only auxlib and 154K solo. Anyway, I still think that is 86K is
> >> not that much to have things like {base, string, table}lib. However,
> >> though I think stdlibs could be in another kmod, I think that is not a
> >> good idea to have auxlib in another one. Lua auxlib is just an
> >> extension of the Lua C API and 12K is really a fair price to have a
> >> more complete Lua library in kernel, IMO.
> >
> > We could for now just go ahead, put auxlib and the stdlibs in lua(4) as
> > foreseen, and when the need arises, we can still factor out the stdlibs
> > to their own kmod.
>
> Agreed. Anyone opposes?
>

Sounds fine.

[Attachment #3 (text/html)]

<p dir="ltr"><br>
On 29 Nov 2013 14:11, &quot;Lourival Vieira Neto&quot; &lt;<a \
href="mailto:lourival.neto@gmail.com">lourival.neto@gmail.com</a>&gt; wrote:<br> \
&gt;<br> &gt; On Fri, Nov 29, 2013 at 10:03 AM, Marc Balmer &lt;<a \
href="mailto:marc@msys.ch">marc@msys.ch</a>&gt; wrote:<br> &gt; &gt; Am 29.11.13 \
12:38, schrieb Lourival Vieira Neto:<br> &gt; &gt;&gt;&gt; It will be interesting to \
see by how much memory the addition of the<br> &gt; &gt;&gt;&gt; standard libraries \
will grow lua(4).   lneto claims it does not grow at<br> &gt; &gt;&gt;&gt; all.   If \
it should, we can still move the standard libraries to a kmod.<br> &gt; &gt;&gt;<br>
&gt; &gt;&gt; I just double checked now (using nm to confirm). In fact, I was<br>
&gt; &gt;&gt; commenting the wrong portion of the Makefile to test. Sorry about \
that<br> &gt; &gt;&gt; =(. Here is the result in amd64: 240K with stdlibs and auxlib, \
166K<br> &gt; &gt;&gt; with only auxlib and 154K solo. Anyway, I still think that is \
86K is<br> &gt; &gt;&gt; not that much to have things like {base, string, table}lib. \
However,<br> &gt; &gt;&gt; though I think stdlibs could be in another kmod, I think \
that is not a<br> &gt; &gt;&gt; good idea to have auxlib in another one. Lua auxlib \
is just an<br> &gt; &gt;&gt; extension of the Lua C API and 12K is really a fair \
price to have a<br> &gt; &gt;&gt; more complete Lua library in kernel, IMO.<br>
&gt; &gt;<br>
&gt; &gt; We could for now just go ahead, put auxlib and the stdlibs in lua(4) as<br>
&gt; &gt; foreseen, and when the need arises, we can still factor out the stdlibs<br>
&gt; &gt; to their own kmod.<br>
&gt;<br>
&gt; Agreed. Anyone opposes?<br>
&gt;</p>
<p dir="ltr">Sounds fine.</p>



[prev in list] [next in list] [prev in thread] [next in thread]