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.)
