Carl-Daniel Hailfinger wrote:
interpreter or other some such would work too. FORTH is just one such interpreter that fills this roll very nicely.
So you'd have been happy with LLShell and RemoteBIOS. There are great tools available, the biggest problem is that nobody knows about them.
I remember LLShell from way long ago. At the time it was far too simplistic to compare with the likes of a forth engine. I've heard mention of RemoteBIOS but not looked at it.
Do both of these systems support looping & branching constructs?
For a real world example take a look at my batman.fth script. http://dev.laptop.org/~rsmith/batman.fth Even if you don't read much forth you can get a feel for the level of coding neeed.
batman.fth has been a life saver for me and OLPC's battery problems. Its possible that I could have written a userspace C program that did the same things as batman, but batman bitbangs the EC's 1-wire pin and the timing is very tight. I'm not sure I could get the microsecond level timing from userspace. Then I would have to have resorted to kernel level code which would have been icky.
free by switching but that was mostly icing. A lot of those type features are now in V3.
Do you have any remaining features missing from v3?
I don't know. I've not used v3 yet. I'm just going off of what I see in the mailing lists with the dt stuff, simplified build structure and LAR.
Assuming 2 MByte/s throughput, dropping the VSA saved only 15 ms load time. Even the whole Linux kernel shouldn't have needed more than 1 second for loading and uncompressing.
Using LAB there was a considerable delay so we must have not been anywhere near 2Mbyte/s.
About the size problem: The 32k or so needed for the VSA are not really a blip on the radar compared to a full Linux kernel. The kernel itself is pretty massive,
Yeah. Like I said we were _really_ close. That 32k might have been just enough.
though, but that's what you get if you want decent hardware support. Fixing OFW to boot properly from all devices (USB disks, SD cards) supported by Linux is still ongoing AFAICS.
There's 2 sides to that story. OFW talks to my Motorola razor phone mass storage fine yet my Ubuntu Hardy Laptop and Debian home system (2 different kernels) throw errors and bail.
OLPC's implementation tries to be optimized for speed rather than broad hardware support. Any device that's standards compliant works fine. You never hear about the 95% of devices that Just Work. Its the 5% funky non-standard ones that make all the noise.
And just because the kernel has broad support for various funky pieces of hardware does not mean using them is was without difficulty. Under LAB it was difficult for the userspace programs to know when the device was ready for use, properly mounted and what /dev/<bla> it was.