Re: Lua-based OS (was: Safe Lua)

[Joshua Phillips <jp.sittingduck@...>]

On Wed 03/Aug/2011, HyperHacker wrote:
> On Wed, Aug 3, 2011 at 06:35, Pierre Chapuis <catwell@archlinux.us> wrote:
> > On Wed, 3 Aug 2011 05:50:38 -0600, HyperHacker wrote:
> >
> >> I have thought about the idea of a Lua-based OS, and it could
> >> certainly be interesting...
> >
> > I too think such a project would be interesting. It has already
> > been tried at least once:
> > http://outofhanwell.wordpress.com/2008/08/16/khoros-a-lua-operating-system/
> > Sadly the source code is no longer accessible.
> >
> > Does anybody here know where it could be found or if there have
> > been other attempts at running a Lua application without OS support?
> >
> > --
> > Pierre Chapuis

I recently ported Lua to work on its own. First I configured Lua to use
integers as lua_Number. Then I disabled the OS and IO libraries, and
implemented the C library functions that Lua needed, and wrote a simple
UART driver in C (it's *very* simple) to interface it. I used Doug Lea's
memory allocator to allocate memory. Then I ported lua.c so that I could
have a command prompt.

Lua doesn't allow you to create arbitrary pointers. A function cannot
obtain access to a table object, for example, except if it is passed
as a parameter or through the environment. It seems to me that Lua
objects would make great capabilities
(http://en.wikipedia.org/wiki/Capability-based_security). No access
checks needed - if a program has the object, they must have been allowed
to use it.

My idea was a single address-space operating system in which all user
code is Lua code (except some trustworthy C modules that can be loaded,
for speed). That, combined with objects-are-capabilities, would make a
rather interesting system.

> I think the basic idea would be to just write a "bootstrap" kernel,
> just enough to set up the machine and load a Lua script from
> somewhere, providing it with functions to access the hardware, so that
> everything from that level on could be done entirely in Lua.

You can include some Lua code in the kernel image, or as multiboot
modules, for bootstrapping.

> A much easier method though might be to hack a Linux kernel. And no
> matter which method you choose, proprietary graphic drivers present a
> problem...

A generic VESA driver should work perfectly well. An OS project has a
(very very) long way to go before video drivers become a problem!

If anyone wants more information about operating system development
(which is surprisingly popular), http://osdev.org/ is a reasonable
starting place.