On Wed, Jun 17, 2015 at 12:17 PM, Andrew Cagney wrote:
> On 17 June 2015 at 00:48, Lourival Vieira Neto
> wrote:
>>>>> Is the kernel's version of Lua available as a library?
>>>>
>>>> You can use it as a regular kernel module. Take a look a
in somewhere? (I couldn't find.)
Moreover, I notice that you've found a bug on the usage of snprintf.
Was this the only one? Please report it next time! =)
--
Lourival Vieira Neto
ddb is not the best way to link Lua into DDB
What's your plan for DDB+Lua? =)
Regards,
--
Lourival Vieira Neto
;
> Can you give me a chance?
If you have interest in Lua in kernel, I would be glad to have your
help. I was actively working on NPF-Lua [1], but it is somehow dormant
now due my current lack of time =(. However, I hope to resume this
project soon.
[1] http://www.netbsd.org/~lneto/eurobsdcon14.pdf
Regards,
--
Lourival Vieira Neto
lease
consider to contact us at LabLua GSoC mailing list [3].
[1] http://www.lua.inf.puc-rio.br
[2] http://www.lua.inf.puc-rio.br/gsoc/ideas2015.html#kerneltest
[3] https://groups.google.com/forum/#!forum/labluagsoc
Regards,
--
Lourival Vieira Neto
Hi Alexander,
On Sat, Jul 12, 2014 at 5:01 PM, Alexander Nasonov wrote:
> Lourival Vieira Neto wrote:
>> Hi folks,
>>
>> Here are some pending patches which I want to commit:
>> http://www.netbsd.org/~lneto/pending/. Please, could someone review
>>
ua(4): cleaned stubs
--
Regards,
--
Lourival Vieira Neto
, int ref);
Removes the ptr from the data object and releases the data-object
reference, allowing it to be garbage-collected. After that, it is safe
to free the ptr pointer.
Regards,
--
Lourival Vieira Neto
Index: lib/lua/data/Makefile
Hi Folks,
Here is a tiny patch that changes the luapmf module for using
luaL_register() function, instead of reimplementing it.
Regards,
--
Lourival Vieira Neto
luapmf-1.patch
Description: Binary data
luacore module to luasystm.
Regards,
--
Lourival Vieira Neto
luasystm-1.patch
Description: Binary data
gt;>>without the __, that is or is exposed to sys/types.h but does
>>>not affect userland.
>>
>> Yes, that's one way of doing it right.
>>
>> Until such time as somebody does it right, please follow the pattern of
>> what's done already.
>
> which is what my suggested patch does.
I got your point.
Regards,
--
Lourival Vieira Neto
Hi Joerg,
On Wed, Dec 4, 2013 at 12:25 PM, Joerg Sonnenberger
wrote:
> On Wed, Dec 04, 2013 at 12:04:23PM -0200, Lourival Vieira Neto wrote:
>> Hi Mindaugas,
>>
>> >> Here is a patch that puts ptrdiff_t in the kernel. It also creates a
>> >> sys/stddef.h he
x.netbsd.org/tech-kern/2013/12/04/msg016211.html.
>>> No, is not allowed in the kernel. Symbols from it are
>>> provided via other means.
>>
>> I know. In fact, I'm asking if it would be alright to allow that.
>> AFAIK, it would be inoffensive if available in the kernel.
>
> Actually, it would be offensive.
Why?
Regards,
--
Lourival Vieira Neto
f.h definition and stddef.h
shouldn't include sys/types.h.
Regards,
--
Lourival Vieira Neto
Hi Folks,
Here is a patch that changes lua_Number to intmax_t, following the
Christos' suggestion in [1]. Lua 5.3 defines lua_Integer as 'long
long', not as int64_t.
[1] http://mail-index.netbsd.org/tech-kern/2013/11/16/msg015956.html
[ ]s,
--
Lourival Vieira Neto
lua_kernel
Hi Folks,
Here is a patch that puts ptrdiff_t in the kernel. It also creates a
sys/stddef.h header.
Regards,
--
Lourival Vieira Neto
ptrdiff_t.patch
Description: Binary data
t. Only _BSD_PTRDIFF_T_ is defined by machine/ansi.h.
The ptrdiff_t type is defined only in stddef.h.
> No, is not allowed in the kernel. Symbols from it are
> provided via other means.
I know. In fact, I'm asking if it would be alright to allow that.
AFAIK, it would be inoffensive if availa
Hi Folks,
Is there a reason to do not have ptrdiff_t defined in the kernel?
Shouldn't be OK to define it in sys/cdefs.h? Or even for having
stddef.h itself in the kernel?
Regards,
--
Lourival Vieira Neto
On Fri, Nov 29, 2013 at 10:03 AM, Marc Balmer 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
uld 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.
Regards,
--
Lourival Vieira Neto
> If the standard libraries should be a separate kmod or if the code
> should just reside in lua(4) is another question.
I really see no reason to put it in another kmod. Moreover, following
the user-space analogy argument, liblua is linked altogether.
Regards,
--
Lourival Vieira Neto
d or not enabled?
IMO, it should be disabled by default. Thus, it would mimic the Lua
library behavior. Where Lua states are created empty and if you want
to use stdlibs, you must explicitly load it (e.g., calling
luaL_openlibs()).
Regards,
--
Lourival Vieira Neto
On Wed, Nov 27, 2013 at 7:23 PM, Martin Husemann wrote:
> Can't it be a per-state option, passed by luactl when creating the state?
I think this is a better option.
Regards,
--
Lourival Vieira Neto
it's just me, but it seems strange to have this depend on a
> (global) sysctl. I assume you have a reason for being able to disable
> it. But if you then want to run other lua code that needs the stdlibs,
> it will be enabled for your original code as well. Did I misunderstand?
Yes, you're right.
Regards,
--
Lourival Vieira Neto
On Tue, Nov 26, 2013 at 9:50 AM, Marc Balmer wrote:
> Am 26.11.13 12:13, schrieb Lourival Vieira Neto:
>> Hi Marc,
>>
>> On Tue, Nov 26, 2013 at 6:18 AM, Marc Balmer wrote:
>>> Am 26.11.13 02:50, schrieb Lourival Vieira Neto:
>>>> Hi Folks,
>>>
Hi Marc,
On Tue, Nov 26, 2013 at 6:18 AM, Marc Balmer wrote:
> Am 26.11.13 02:50, schrieb Lourival Vieira Neto:
>> Hi Folks,
>>
>> Here is a patch that puts some Lua standard libraries into the kernel:
>>
>> - Auxiliary library (C API);
>> - Base library;
On Tue, Nov 26, 2013 at 6:22 AM, Marc Balmer wrote:
> Am 26.11.13 03:26, schrieb Lourival Vieira Neto:
>> Hi again..
>>
>> Just a tiny patch to use luaL_register() on luacore kernel module.
>>
>> Regards
>
> You are now using the auxiliary library, whi
Hi again..
Just a tiny patch to use luaL_register() on luacore kernel module.
Regards
--
Lourival Vieira Neto
lua_kernel_luacore.patch
Description: Binary data
On Tue, Nov 26, 2013 at 12:08 AM, Paul Goyette wrote:
> Hopefully, this actually puts the libraries into the _optional_ lua kernel
> module, and not into the kernel itself?
>
> :)
heh.. course.. s/kernel/Lua kernel module/ =)
Regards,
--
Lourival Vieira Neto
Hi Folks,
Here is a patch that puts some Lua standard libraries into the kernel:
- Auxiliary library (C API);
- Base library;
- String library;
- Table library.
Regards,
--
Lourival Vieira Neto
lua_kernel_stdlib.patch
Description: Binary data
On Sun, Nov 24, 2013 at 10:06 PM, James K. Lowden
wrote:
> On Sat, 23 Nov 2013 11:46:19 -0200
> Lourival Vieira Neto wrote:
>> On Sat, Nov 23, 2013 at 1:22 AM, James K. Lowden
>> wrote:
>> > On Mon, 18 Nov 2013 09:07:52 +0100
>> > Marc Balmer wrote:
>&
On Sat, Nov 23, 2013 at 11:46 AM, Lourival Vieira Neto
wrote:
> Hi James,
>
> On Sat, Nov 23, 2013 at 1:22 AM, James K. Lowden
> wrote:
>> On Mon, 18 Nov 2013 09:07:52 +0100
>> Marc Balmer wrote:
>>
>>> After discussion we lneto@ and others we realised th
ata might be.)
I don't think that Marc meant 'structured binary data' in opposition
to 'unstructured binary data'. We both are working with structured
data. The main difference is that I'm working on random accessing and
he is working on encoding/decoding data at once (e.g., x, y, z =
d:extract(fmt)).
Regards,
--
Lourival Vieira Neto
On Wed, Nov 20, 2013 at 10:38 AM, Marc Balmer wrote:
> Am 20.11.13 13:33, schrieb Lourival Vieira Neto:
>> On Wed, Nov 20, 2013 at 6:36 AM, Marc Balmer wrote:
>>> Am 18.11.13 09:07, schrieb Marc Balmer:
>>>> Am 17.11.13 13:05, schrieb Marc Balmer:
>>&g
ork to
>> remove the non portable parts, but that's not far off. Happy to switch
>> but I do need access to struct members like tables, nested structs,
>> unions, casts, metatables for structs. If there was an outline design
>> doc that would be helpful.
>
> I suggest we discuss this library in Toulouse, OK?
I think it would be very nice. But, please send me your thoughts after =).
--
Lourival Vieira Neto
ed, it will go by the name 'data' and be available for
> "both" Luas.
'Data' is fine for me; I don't have a better suggestion anyway =).
> @lneto: I will start with the pack/unpack parts, you can then add your
> stuff whenever you want, ok?
Just fine for me. However, I think we need to define the API before
(re)starting coding.
Regards,
--
Lourival Vieira Neto
On Sun, Nov 17, 2013 at 7:57 PM, Marc Balmer wrote:
> Am 17.11.13 14:43, schrieb Lourival Vieira Neto:
>> On Sun, Nov 17, 2013 at 11:23 AM, Marc Balmer wrote:
>>> Am 17.11.13 13:32, schrieb Hubert Feyrer:
>>>> On Sun, 17 Nov 2013, Marc Balmer wrote:
>>&g
On Sun, Nov 17, 2013 at 6:45 PM, Justin Cormack
wrote:
> On Sun, Nov 17, 2013 at 8:39 PM, Lourival Vieira Neto
> wrote:
>> Well, I don't think I fully understood that; mainly because I'm not
>> aware about Lua 5.3. It will provide two number types for the scripts
On Sun, Nov 17, 2013 at 6:13 PM, Justin Cormack
wrote:
> On Sun, Nov 17, 2013 at 7:56 PM, Christos Zoulas wrote:
>> On Nov 17, 3:36pm, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
>> -- Subject: Re: [patch] changing lua_Number to int64_t
>>
>> | > 1. Lu
instead of moving it to pkgsrc somehow.
>
> This...
I think that would be nice to have Lua kernel modules in pkgsrc, if possible.
Regards,
--
Lourival Vieira Neto
On Sat, Nov 16, 2013 at 9:25 PM, Lourival Vieira Neto
wrote:
> (...) I moved strtoimax.c to common/libc. Don't know if
> someone sees a problem on that.
BTW, is it OK? Could someone review this?
Regards,
--
Lourival Vieira Neto
On Sun, Nov 17, 2013 at 3:10 PM, Justin Cormack
wrote:
> On Sun, Nov 17, 2013 at 4:52 PM, Lourival Vieira Neto
> wrote:
>> On Sun, Nov 17, 2013 at 2:02 PM, Christos Zoulas wrote:
>>> On Nov 17, 10:46am, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
>>> --
On Sun, Nov 17, 2013 at 2:02 PM, Christos Zoulas wrote:
> On Nov 17, 10:46am, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
> -- Subject: Re: [patch] changing lua_Number to int64_t
>
> | On Sun, Nov 17, 2013 at 7:37 AM, Marc Balmer wrote:
> | > Am 17.11.13 04:49, s
On Sun, Nov 17, 2013 at 12:58 PM, Christos Zoulas wrote:
> On Nov 17, 1:36am, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
> -- Subject: Re: [patch] changing lua_Number to int64_t
>
> | > Bigger is better. And you can use %jd to print which is a big win.
> |
> | I
he future.
LHF has lpack library [1], it could be an alternative to Roberto's struct.
[1] http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/#lpack
Regards,
--
Lourival Vieira Neto
(as happens with Lua in
> userspace now). As the widest type in the kernel is int64_t thats
> what Lua should use. (The issue of uint64_t is left as an exercise for
> the Lua programmer). When/if the kernel uses something longer then Lua
> can change, but using intmax_t is not useful as the kernel is explicit
> about sizes.
Indeed.
Regards,
--
Lourival Vieira Neto
Lua user-space libraries should be painful
enough independently of lua_Number type. IMHO, the main point here is
to define a lua_Number type adjusted to kernel needs. As, we have
already broke compatibility with user space libraries (for several
factors, not only the missing of floating point number), I think it
shouldn't matter much now.
Regards,
--
Lourival Vieira Neto
ss. Thanks for making it clear.
Sorry, I thought that it was clear.
Regards,
--
Lourival Vieira Neto
. Lua scripts will hardly depend on
> the size of an integer.
But they could. I think that the script programmers should know if the
numeric data type is enough for their usage (e.g., time diffs).
Regards,
--
Lourival Vieira Neto
On Sun, Nov 17, 2013 at 7:35 AM, Marc Balmer wrote:
> Am 17.11.13 04:36, schrieb Lourival Vieira Neto:
>> On Sat, Nov 16, 2013 at 10:44 PM, Christos Zoulas
>> wrote:
>>> On Nov 16, 9:30pm, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
>>> -- Subject: R
On Sun, Nov 17, 2013 at 3:30 AM, Terry Moore wrote:
>> From: Lourival Vieira Neto [mailto:lourival.n...@gmail.com]
>> > Watch out, by the way, for compiled scripts; I have not checked Lua 5.x,
> but
>> > you may find if not careful that the compiled binary is not loa
It isn't safe.
Regards,
--
Lourival Vieira Neto
On Sat, Nov 16, 2013 at 10:44 PM, Christos Zoulas wrote:
> On Nov 16, 9:30pm, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
> -- Subject: Re: [patch] changing lua_Number to int64_t
>
> | On Sat, Nov 16, 2013 at 8:52 PM, Christos Zoulas
> wrote:
> | > In a
On Sat, Nov 16, 2013 at 9:47 PM, Alexander Nasonov wrote:
> Lourival Vieira Neto wrote:
>> On Sat, Nov 16, 2013 at 8:52 PM, Christos Zoulas wrote:
>> > In article <52872b0c.5080...@msys.ch>, Marc Balmer wrote:
>> >>Changing the number type to in
as a well-defined width and, AFAIK,
intmax_t could vary. But I have no strong feelings about this. Do you
think intmax_t would be better?
Regards,
--
Lourival Vieira Neto
#x27;ve adjusted the
patch. Now, I'm using (int64_t) strtoimax() instead of strtoll(). I
think it should be alright because intmax_t is always greater or equal
than int64_t. I moved strtoimax.c to common/libc. Don't know if
someone sees a problem on that.
The patch is att
fixed a little issue.. (s/LUA_NUMBER_SCAN "%"PRId64/LUA_NUMBER_SCAN
"%"SCNd64).. sorry about that.. =/
On Sat, Nov 16, 2013 at 12:55 AM, Lourival Vieira Neto
wrote:
> *is
>
> On Sat, Nov 16, 2013 at 12:53 AM, Lourival Vieira Neto
> wrote:
>> Hi Folk
*is
On Sat, Nov 16, 2013 at 12:53 AM, Lourival Vieira Neto
wrote:
> Hi Folks,
>
> Here are a patch that changes lua_Number from 'long long' to 'int64_t'.
>
> Regards,
> --
> Lourival Vieira Neto
--
Lourival Vieira Neto
Hi Folks,
Here are a patch that changes lua_Number from 'long long' to 'int64_t'.
Regards,
--
Lourival Vieira Neto
lua_kernel_int64_t.patch
Description: Binary data
On Thu, Oct 24, 2013 at 5:41 AM, Marc Balmer wrote:
> Am 21.10.13 00:05, schrieb Christoph Badura:
>> On Tue, Oct 15, 2013 at 06:01:29PM -0300, Lourival Vieira Neto wrote:
>>>> Also, having to switch mentally between zero-based arrays in the kernel C
>>>> code a
Hi Artem,
On Wed, Oct 23, 2013 at 5:10 PM, Artem Falcon wrote:
>> On Tue, Oct 15, 2013 at 06:01:29PM -0300, Lourival Vieira Neto wrote:
>> > > Also, having to switch mentally between zero-based arrays in the
>> > > kernel C
>> > > code and 1-base
to
provide array access (see below).
On Sun, Oct 20, 2013 at 8:05 PM, Christoph Badura wrote:
> On Tue, Oct 15, 2013 at 06:01:29PM -0300, Lourival Vieira Neto wrote:
>> > Also, having to switch mentally between zero-based arrays in the kernel C
>> > code and 1-based arrays in
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?
The code is not linked yet.
Regards,
--
Lourival Vieira Neto
dicial. 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
haven't committed anything nor tried to impose nothing. 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.
Regards,
--
Lourival Vieira Neto
On Fri, Oct 18, 2013 at 9:08 AM, Taylor R Campbell wrote:
>Date: Thu, 17 Oct 2013 19:16:16 -0300
>From: Lourival Vieira Neto
>
>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
I'm not arguing that we need that. I'm just arguing that I
see benefits and none harm.
Regards,
--
Lourival Vieira Neto
in 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.
[1] https://github.com/dergraf/PacketScript
[2] http://www.pdsw.org/pdsw12/papers/grawinkle-pdsw12.pdf
> +j
>
Regards,
--
Lourival Vieira Neto
g. It looks really interesting [1]. I'll
take a deeper look later. Thanks!
Regards,
--
Lourival Vieira Neto
On Wed, Oct 16, 2013 at 3:50 AM, Marc Balmer wrote:
> Am 15.10.13 23:01, schrieb Lourival Vieira Neto:
>
> [...]
>
>>> Also, having to switch mentally between zero-based arrays in the kernel C
>>> code and 1-based arrays in the Lua code make my head ache.
>>
&
Hi Justin,
On Tue, Oct 15, 2013 at 7:38 PM, Justin Cormack
wrote:
> On Thu, Oct 10, 2013 at 7:15 PM, Lourival Vieira Neto
> wrote:
>> Hi folks,
>>
>> It has been a long time since my GSoC project and though I have tried
>> to come back, I've experienced som
On Tue, Oct 15, 2013 at 7:22 PM, Alexander Nasonov wrote:
> Lourival Vieira Neto wrote:
>> I'm developing a library to handle buffers in Lua, named lbuf. It is
>> been developed as part of my efforts to perform experimentation in
>> kernel network stack using Lua. Ini
with you.
In fact, I really want to commit that changing, but we need to have
the code in tree for that.
Regards,
--
Lourival Vieira Neto
based arrays in the Lua code make my head ache.
It's something that doesn't bug me so much.. But, if necessary it
could be changed to 0-based in this userdata.
> On Thu, Oct 10, 2013 at 03:15:54PM -0300, Lourival Vieira Neto wrote:
>> C API:
>>
>> lbuf_new(lua_St
; 1 return DROP end
end
return PASS
end
The code is hosted in https://github.com/lneto/lbuf. Currently, only
array and raw access are working (partially).
I think this API could be useful for device-driver and protocol
prototyping. Looking forward to hearing from you.
Regards,
--
Lourival Vieira Neto
On Mon, Nov 8, 2010 at 8:46 PM, Antti Kantee wrote:
> On Mon Nov 08 2010 at 20:32:14 -0200, Lourival Vieira Neto wrote:
>> >> > Right... so how do you restore the kernel to a valid state?
>> >>
>> >> Why wouldn't it be a valid state after a script cr
On Tue, Oct 19, 2010 at 8:10 AM, Antti Kantee wrote:
> On Tue Oct 05 2010 at 18:24:48 -0300, Lourival Vieira Neto wrote:
>> Hi folks,
>>
>> I'm glad to announce the results of my GSoC project this year [1].
>> We've created the support for scripting the NetBS
On Tue, Oct 19, 2010 at 8:23 AM, Antti Kantee wrote:
> On Tue Oct 12 2010 at 02:17:35 -0300, Lourival Vieira Neto wrote:
>> On Tue, Oct 12, 2010 at 1:50 AM, David Holland
>> wrote:
>> > On Tue, Oct 12, 2010 at 12:53:10AM -0300, Lourival Vieira Neto wrote:
>> >
anks,
> --
> Matt
>
[1] http://marc.info/?l=lua-l&m=128676702329567&w=2
[2] http://marc.info/?l=lua-l&m=128676669829325&w=2
Cheers,
--
Lourival Vieira Neto
On Tue, Oct 12, 2010 at 3:47 AM, Alan Barrett wrote:
>
> [cross-posting removed]
>
> On Tue, 05 Oct 2010, Lourival Vieira Neto wrote:
>> We've created the support for scripting the NetBSD kernel with Lua,
>
> Instead of using "long long" as the C data ty
On Tue, Oct 12, 2010 at 1:50 AM, David Holland wrote:
> On Tue, Oct 12, 2010 at 12:53:10AM -0300, Lourival Vieira Neto wrote:
> > > > > A signature only tells you whose neck to wring when the script
> > > > > misbehaves. :-) Since a Lua script running in the k
On Tue, Oct 12, 2010 at 12:32 AM, David Holland
wrote:
> On Sat, Oct 09, 2010 at 07:34:43PM -0300, Lourival Vieira Neto wrote:
> > > A signature only tells you whose neck to wring when the script
> > > misbehaves. :-) Since a Lua script running in the kernel won't
On Sun, Oct 10, 2010 at 10:45 PM, Samuel Greear wrote:
> On Tue, Oct 5, 2010 at 3:24 PM, Lourival Vieira Neto
> wrote:
>> Hi folks,
>>
>> I'm glad to announce the results of my GSoC project this year [1].
>> We've created the support for scripting the Ne
ope you continue working on this, I see potential and at some point
> I would like to evaluate this for inclusion in DragonFly BSD.
It would be great =).
[1] http://www.lua.org/manual/5.1/luac.html
Cheers,
--
Lourival Vieira Neto
it with his own rules; and so on..
Cheers,
--
Lourival Vieira Neto
restricting access to each Lua environment. For
example, a script running in packet filtering should have access to a
different set of kernel functions than a script running in process
scheduling. Moreover, we could restrict also the access for users
loading scripts. For example, we could accept only scripts loaded by
users from the "scheduler" group for defining a scheduling script.
Cheers,
--
Lourival Vieira Neto
e nice for new-style kernel modules, too,
> especially if part of future plans for supporting them include
> eventually providing binary-only upgrades of some components).
> A build-time inclusion of the wanted public keys to trust third party
> components from would not be hard to implement...
>
> Thanks,
> --
> Matt
>
Cheers,
--
Lourival Vieira Neto
On Wed, Oct 6, 2010 at 6:23 AM, jean-Yves Migeon wrote:
>
> On Tue, 5 Oct 2010 18:24:48 -0300, Lourival Vieira Neto
> wrote:
>> I'm glad to announce the results of my GSoC project this year [1].
>> We've created the support for scripting the NetBSD kernel with Lua,
760748
[2] http://netbsd-soc.sourceforge.net/projects/luakern/
Cheers,
--
Lourival Vieira Neto
786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
> | Kernel Developer | | pgoyette at netbsd.org |
> -
>
Cheers,
--
Lourival Vieira Neto
90 matches
Mail list logo
