lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Mon, Feb 18, 2013 at 1:04 AM, Ross Bencina
<> wrote:
> Hi Rena,
> You might want to look at Khoros if you haven't already:
> Ross.
> On 18/02/2013 4:37 PM, Rena wrote:
>> On Mon, Feb 18, 2013 at 12:13 AM, marbux <> wrote:
>>> On Sun, Feb 17, 2013 at 6:45 PM, Steve Litt <>
>>> 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:
>>> * <>. 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
>>> <>.
>>> 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.