Re: Lua OS

[Rena <hyperhacker@...>]

On Mon, Feb 18, 2013 at 1:04 AM, Ross Bencina
<rossb-lists@audiomulch.com> wrote:
> Hi Rena,
>
> You might want to look at Khoros if you haven't already:
>
> http://outofhanwell.wordpress.com/2008/08/16/khoros-a-lua-operating-system/
>
> Ross.
>
>
> On 18/02/2013 4:37 PM, Rena wrote:
>>
>> On Mon, Feb 18, 2013 at 12:13 AM, marbux <marbux@gmail.com> wrote:
>>>
>>> On Sun, Feb 17, 2013 at 6:45 PM, Steve Litt <slitt@troubleshooters.com>
>>> wrote:
>>>>
>>>> On Mon, 23 Apr 2012 14:22:43 +0300
>>>
>>>
>>>> Please, please, PLEASE tell me how to make an eLua bootable CD that can
>>>> bring up the eLua shell so I can show that off at my local LUG (GoLUG).
>>>> If eLua can recognize and mount a thumb drive so I can store Lua
>>>> programs on there, and then bring them up with either the lua command
>>>> or the recv command, please tell me how to do that too.
>>>>
>>>> I'm telling you, a five minute discussion of this would send all the
>>>> GoLUGgers into outer space. Also, I have some connections with the
>>>> local FamiLAB, and could demonstrate this there.
>>>>
>>>> I looked
>>>
>>>
>>> What I know about eLua I learned in the last 10 minutes. :-) But check:
>>>
>>> * <http://wiki.eluaproject.net/Tutorials>. Topics that might get you
>>> part of the way there:
>>>
>>>    Booting eLua on a PC - Using standalone eLua on a desktop PC
>>>    Booting eLua from an USB stick - Booting eLua from a pendrive on
>>> your desktop PC
>>>
>>> They say you can't have file system support that way, but those pages
>>> were last edited in 2010. So you might consider asking your questions
>>> on the eLua-dev mailing list or the #lua IRC channel on freenode.
>>> Contact information is at
>>> <http://www.eluaproject.net/get-involved/community-resources>.
>>>
>>> Best regards,
>>>
>>> Paul
>>>
>>
>> I've pondered the idea of an OS mostly written in Lua, and indeed
>> might try it someday when I'm bored. I think the best approach would
>> be a bootstrap program in C, that handles the low-level initialization
>> (switching the CPU into 32/64-bit mode, loading the kernel from disk,
>> etc) and creates a Lua state, giving it some useful functions to do
>> things like direct memory/hardware I/O so it can talk to the hardware,
>> and calling an init script (effectively the kernel). That would get
>> you Lua running on bare metal, capable of doing some simple things
>> like beeping the speaker.
>>
>> That "kernel" script can then load other scripts (probably creating
>> them in separate states, in other threads) that do things like talk to
>> the hardware (perhaps giving them more limited memory I/O functions,
>> that let them talk to the hardware they're operating, but not access
>> other memory regions), set up a display, load user applications (also
>> scripts, but they could possibly be allowed to load C libraries in
>> some limited manner?), and all those other nice things an OS does.
>>
>> The main thing that I suspect could be an issue is memory management.
>> At the lowest levels, you want to be able to directly allocate memory
>> at particular addresses, not rely on garbage collection. I'm not sure
>> what'd be the best way to get around that, since Lua is really not
>> designed for manual memory management - even simple things like
>> functions and tables are heap-allocated objects that would be
>> collected. Perhaps it'd be possible for the kernel to run a modified
>> version of Lua (or a C library that pokes into Lua's innards) that
>> doesn't do any garbage collection (or can we just turn it off?) and
>> uses a "free" function to manually collect objects. That'd be
>> difficult to use, as you'd have to manually free every table, function
>> etc you create, but you'd try to write as little as possible at that
>> level, just enough to set up memory management enough that the rest
>> can run in a normal Lua state with normal garbage collection.
>>
>> An interesting idea that comes to mind as well is that since Lua
>> doesn't have the concept of pointers, a script can't just try to write
>> to arbitrary memory or execute arbitrary machine code. What a Lua
>> script can do depends entirely on what functions are available to
>> it... in other words, capability-based security becomes feasible at
>> the application level. If an app isn't granted permission to access
>> some resource, then the functions to access it aren't introduced into
>> its state; if you want to allow it to access only certain directories,
>> you don't give it a function that can access any directory, but a
>> wrapper that checks if the requested directory is allowed.
>>
>> The biggest issue I can see with that idea is that there'd always be
>> danger of "leaking" privileged objects; maybe your app doesn't have
>> permission to write to memory directly, so it doesn't have the
>> "memory.write" function, but it has access to some object whose
>> metatable refers (probably indirectly through several more objects) to
>> that function, that means your app can get hold of the function that
>> way and write wherever it likes, and now you're pwned. It'd take
>> careful design to avoid this kind of leakage. (Or the function would
>> have to check which app is attempting to call it, but that defeats the
>> purpose of capability-based security, and complicates the design, as
>> now that function needs to know the difference between that object
>> buried under 7 layers of indirection that's supposed to use it, and
>> the application code that's managed to get hold of it.)
>>
>

That is an interesting article. It sounds like they've done a lot of
the same ideas I had in mind. Using Grub instead of a custom
bootloader strikes me as a particularly good idea. It's interesting
though that they're using coroutines instead of actual OS threads for
multithreading; while it's possible to "fake" preemptive threading
using debug hooks, that only works as long as the app stays in Lua; a
long-running C function (which can be even simple string manipulation
with very large strings) would block all other threads. It also
doesn't allow to easily take advantage of parallel processor cores.

I feel like the best domain for a new OS right now is on smartphones
and tablets rather than PCs. It's just a shame that it usually takes
some kind of bootloader exploit to be able to install an alternate OS
on those devices. Of course a well-designed OS should be able to run
fine on PCs, phones, microwaves and whatever else, as *n*xes do, so
it'd be possible to design it on a PC (probably in a VM for the most
part) before moving to other platforms.

-- 
Sent from my Game Boy.