Date: Tue, 2 Sep 2014 15:32:11 -0400 From: Walt Ford <walt.ford@yahoo.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Alfred Perlstein <bright@mu.org>, freebsd-arch@freebsd.org Subject: Re: script(2) [was: [CFT/review] new sendfile(2)] Message-ID: <20140902193211.GA29155@nbu> In-Reply-To: <40210.1409607245@critter.freebsd.dk> References: <20140529102054.GX50679@FreeBSD.org> <20140729232404.GF43962@funkthat.com> <20140831165022.GE7693@FreeBSD.org> <540382E2.3040004@freebsd.org> <2770.1409522711@critter.freebsd.dk> <5403B13C.60008@freebsd.org> <4204.1409549879@critter.freebsd.dk> <5404D1B8.9010006@mu.org> <40210.1409607245@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 01, 2014 at 09:34:05PM +0000, Poul-Henning Kamp wrote: > In message <5404D1B8.9010006@mu.org>, Alfred Perlstein writes: >>> In message <5403B13C.60008@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140902193211.GA29155>