script(2) [was: [CFT/review] new sendfile(2)]

Johan Bucht jbucht at gmail.com
Wed Sep 3 10:57:48 UTC 2014


Example of Lua packet filtering:

http://wingolog.org/archives/2014/09/02/high-performance-packet-filtering-with-pflua


On Tue, Sep 2, 2014 at 9:32 PM, Walt Ford via freebsd-arch <
freebsd-arch at freebsd.org> wrote:

> On Mon, Sep 01, 2014 at 09:34:05PM +0000, Poul-Henning Kamp wrote:
> > In message <5404D1B8.9010006 at mu.org>, Alfred Perlstein writes:
> >>> In message <5403B13C.60008 at freebsd.org>, Alfred Perlstein writes:
> >>>
> >>>> Lua at the syscall level makes sense. :)
> >>> I doubt it.
> >>>
> >>> We're looking at high performance stuff and we don't want a silly
> >>> parser and string processing involved.
> >>>
> >>Would it really matter?  Lua is bytecode, [...]
> >
> > I though you wanted the interpreter in the kernel.
> >
> > If it's only the executor, then ... maybe...
> >
> > We'd need to do a serious audit of the lua bytecode first...
>
> I've been sort of working on a Lua-based FreeBSD for years in my spare
> time just because I love both so much.  I could be wrong, but I think
> making use of Lua in-kernel would require modifying the interpreter to
> include the kernel's idea of locks, mutexes, memory barriers, and threads.
> In Lua, threads and their safety must be written by end-users last I knew,
> but I don't follow Lua development closely.
>
> At least in my latest work, trying to replace init_main.c and mi_startup()
> with a Lua script, all of that is necessary.  Really, I'd even need the
> interpreter to be aware of the FreeBSD scheduler for a Lua-based mi_startup
> to be workable.
>
> I've got a lot of Lua bits and pieces in userland utilities, libraries,
> and now init_main.c is in boot/ but none of it works yet.  I have visions
> of a FreeBSD that unboot backwards to reload subsystems, but I'm not
> close.
>
> --
> Walt
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>


More information about the freebsd-arch mailing list