Date: Wed, 1 Mar 2017 08:51:03 -0700 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@freebsd.org> Cc: Julian Elischer <julian@freebsd.org>, Allan Jude <allanjude@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Saurav Sachidanand <sauravsachidanand@gmail.com> Subject: Re: [GSoC 2017] Original proposal: Port kernel Lua to FreeBSD Message-ID: <CANCZdfoYk1v9axkT0CqUbCWOaoPrEDoJRPpPk0kk5GDjDE=-fw@mail.gmail.com> In-Reply-To: <1488383213.60166.10.camel@freebsd.org> References: <CACKq%2BiX_V2MY9sNf-buEOO1S87dbhDv%2BPGbUEqRUVkvzz3pdvw@mail.gmail.com> <244231A2-EB18-4E58-A2B2-927F55D54950@FreeBSD.org> <CANCZdfpiiJLyLbEQnk86mfwf07JGByq5oT_1-T43iEhscEEgMg@mail.gmail.com> <f221e624-1342-7548-a3f9-806a1d25b90d@freebsd.org> <1488383213.60166.10.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 1, 2017 at 8:46 AM, Ian Lepore <ian@freebsd.org> wrote: > On Wed, 2017-03-01 at 16:14 +0800, Julian Elischer wrote: >> On 28/2/17 2:01 am, Warner Losh wrote: >> > >> > On Mon, Feb 27, 2017 at 8:26 AM, Allan Jude <allanjude@freebsd.org> >> > wrote: >> > > >> > > On February 27, 2017 5:28:41 AM PST, Saurav Sachidanand <sauravsa >> > > chidanand@gmail.com> wrote: >> > > > >> > > > Hello FreeBSD community, >> > > > >> > > > I'm >> > > > Saurav Sachidanand, and I'm >> > > > a CS sophomore studying in India >> > > > . >> > > > I have an interest in operating systems development and wish to >> > > > contribute >> > > > to the FreeBSD community. I'm proficient with C and have some >> > > > experience in >> > > > kernel programming. Hence, I'd like to propose an original >> > > > project for >> > > > GSoC >> > > > 2017 that I feel would benefit this community. >> > > > >> > > > In past years, the Lua interpreter was ported to run inside the >> > > > Linux >> > > > and >> > > > NetBSD kernel [1]. Lua was chosen because it's interpreter is >> > > > very >> > > > small (~240 >> > > > KB) compared to that of Python or Ruby, it's MIT licensed, and >> > > > is >> > > > almost >> > > > freestanding. A working demonstration of it is a packet >> > > > filtering >> > > > algorithm >> > > > written entirely in kernel Lua [2]. >> > > > >> > > > Specifically, my proposal would be to port the following that >> > > > are >> > > > currently >> > > > written for NetBSD: >> > > > - the modified Lua VM source code with _KERNEL preprocessor >> > > > directives >> > > > to >> > > > exclude user-space functionality like floating point, the io >> > > > and os >> > > > module >> > > > in the standard library, etc. [3] >> > > > - the kernel module device driver for /dev/lua, to which Lua >> > > > scripts >> > > > are >> > > > fed to be executed [4], [5] >> > > > - the luactl user-space program to control the Lua device and a >> > > > couple >> > > > of >> > > > sysctl variables which serve similar purpose [6], [7] >> > > > >> > > > And then: >> > > > - run the Lua test suite targeting whatever we support in the >> > > > kernel to >> > > > make sure it works [8] >> > > > - and write Lua bindings to the kernel interfaces that would >> > > > interest >> > > > the >> > > > FreeBSD community >> > > > >> > > > Since NetBSD and FreeBSD have similar kernel interfaces >> > > > (mutexes, >> > > > linked >> > > > lists, device switch interface), the porting shouldn't involve >> > > > too much >> > > > code refactoring. Also, this would all be an experiment in that >> > > > we >> > > > don't >> > > > fully know what the real world use cases might be, but it would >> > > > attract >> > > > more people to writing kernel code who otherwise wouldn't >> > > > because of >> > > > having >> > > > to do everything in C. And it would be interesting to carry out >> > > > it out >> > > > in >> > > > FreeBSD as well since it has a larger community than NetBSD. >> > > > >> > > > I humbly request anyone who is interested in this project to be >> > > > my >> > > > potential mentor(s) for GSoC. >> > > > >> > > > More slides on kernel Lua in NetBSD - [9], [10]. >> > > > >> > > > Thanks, >> > > > Saurav >> > > > >> > > > [1] - http://www.netbsd.org/~lneto/dls14.pdf >> > > > [2] - https://www.netbsd.org/~lneto/eurobsdcon14.pdf >> > > > [3] - https://github.com/jsonn/src/tree/trunk/external/mit/lua/ >> > > > dist/src >> > > > [4] - >> > > > https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sys/module >> > > > s/lua >> > > > [5] - >> > > > https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sys/module >> > > > s/luasystm >> > > > [6] - https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sbin >> > > > /luactl >> > > > [7] - http://netbsd.gw.com/cgi-bin/man-cgi?lua+4+NetBSD-current >> > > > [8] - http://www.lua.org/tests/ >> > > > [9] - >> > > > https://www.netbsd.org/gallery/presentations/mbalmer/fosdem2012 >> > > > /kernel_mode_lua.pdf >> > > > [10] - https://www.lua.org/wshop13/Cormack.pdf >> > > > _______________________________________________ >> > > > freebsd-hackers@freebsd.org mailing list >> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> > > > To unsubscribe, send any mail to >> > > > "freebsd-hackers-unsubscribe@freebsd.org" >> > > This may be quite a nice thing to have. Another upcoming use for >> > > LUA in the kernel is ZFS Channel Programs. These allow a number >> > > of ZFS operations to be completed as a single atomic transaction. >> > > >> > > I would hope we could structure this in such a way as to not end >> > > up with two copies of Lua in the kernel. >> > There's also a 3/4 finished lua in the boot loader that you might >> > be >> > able to leverage as well.... >> I'd like to see that finished. While Devin has done Heroic work with >> the forth in the loader, I think it's time has come. >> It' be nice to have something a little less '60s. >> >> > >> > >> > Warner > > I was under the impression that the "lua in bootloader" work was > basically done and just needed testing, which nobody has done. I think > it's all sitting in the projects/lua-bootloader branch in svn. The branch compiles. Testing has been done, but there's some missing bits. It basically kinda works for the average case, but more advanced uses of the bootloader still have sharp pointy edges on them, the extent of the pointy edges is unknown. At this point the rebasing of the branch is non-trivial due to the merge conflicts that have crept in. They don't look awful, but when I tried to use git to rebase to a more modern FreeBSD, there were lots of stupid things. Maybe I'll try again... Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoYk1v9axkT0CqUbCWOaoPrEDoJRPpPk0kk5GDjDE=-fw>