DRLX 1.0 Ships; Simplifies Deployment of Linux-Based Embedded System Applications [LWN.net]

DRLX 1.0 Ships; Simplifies Deployment of Linux-Based Embedded System Applications

Posted Mar 30, 2004 3:10 UTC (Tue) by corbet (editor, #1) [Link]

Devicelogics is also headed up by Bryan Sparks, a Caldera founder who went on to run Lineo. What that means, I don't know...

DRLX 1.0 Ships; Simplifies Deployment of Linux-Based Embedded System

Posted Mar 30, 2004 19:43 UTC (Tue) by tbird20d (subscriber, #1901) [Link]

Bryan Sparks is a "white hat" in the history of Linux. I worked at
early Caldera, and at Lineo with Bryan, and he's a great guy.
The association with Canopy is weird, but Canopy ended up with
the DRDOS asset after the lawsuit (successfully settled out of
court) with Microsoft, and when Lineo switched completely over
to Linux, DRDOS was essentially commercially abandoned.

It's nice to see it live on in some form. Most people don't realize
it, but at one time DRDOS was the #1 embedded OS of
karaoke machines!! There are still people running DRDOS for
legacy embedded applications, and hopefully this will allow
just a little more life to be wrung out of the venerable
technology.

Although, I'm reminded of a snippet from the "Tao of Programming"...

A master was explaining the nature of Tao of to one of his novices.

``The Tao is embodied in all software - regardless of how insignificant,'' said the master.

``Is the Tao in a hand-held calculator?'' asked the novice.

``It is,'' came the reply.

``Is the Tao in a video game?'' continued the novice.

``It is even in a video game,'' said the master.

``And is the Tao in the DOS for a personal computer?''

The master coughed and shifted his position slightly. ``The lesson is over for today,'' he said.

"Going back" is not a function of the loader ...

Posted Mar 30, 2004 12:30 UTC (Tue) by AnswerGuy (guest, #1256) [Link]

MS-DOS and its compatibles are designed to load programs leaving behind a stub for them to return into. However, they don't manage system resources beyond that, other than providing for a small set of file access services on FAT filesystems.

There was/is a primitive co-operative multi-tasking feature which allowed a TSR (terminate and stay resident) program (like a print spooler) to hook into a given interrupt (a clock service routine) which was generally either left alone or co-operatively hooked into by loaded programs.

Upon exit from a loaded program a routine was called in the resident portion of the DOS command shell which would perform a memory checksum and reload the rest of the command shell if necessary. Thus the execution of small utilities usually left all of DOS resident while larger applications used up more memory and wiped out this "overlay."

(Memory management by "overlay" --- loading different library/code into memory to execute it, the overwriting that with other library/code as necessary to perform other processsing; was common in MS-DOS and on other non-virtual memory systems. Of course this required linking with a specific set of libraries and coding to an explicit set of APIs and various overlay management libraries had their own limitations; there were also "DOS extenders" which added similar features in "expanded" memory using the LIM (Lotus Intel Microsoft) EMS (expanded memory spec.)).

My point?

Whether one can return from Linux to its loader (MS-DOS or any of its clones: DR DOS, FreeDOS, etc) is a primarily function of Linux rather than of the loader. Specifically the kernel need only preserve the memory image of the resident loader/OS code (either by leaving it allocated and pinned into real memory as if it was some sort of device driver, or more sensibly, marking it as virtual and paging it out to swap until it's needed). Then the Linux shutdown system call need only restore this memory, clean up some other memory, shift out of protected mode and return back to its loader like any old DOS program (particularly one that was linked via a DOS extender) would have done.

Personally I think the whole execise is relatively pointless. It makes for a nice press release (relying on the growing popularity and media interest in Linux to gain the "eye" time of reporters). DR DOS undoubtedly does have a much smaller footprint than Linux. However, DR DOS as a loader for a Linux kernel clearly cannot (in the general case). Thus we'd have to ask what build options this arrangement allows that would save footprint (memory and/or disk space utilization of a Linux kernel and ancillary files).

When you look at the various Linux compile time options and the further modularity that's been achieved by some embedded systems developers (effectively patching the mainstream sources to make more stuff optional) it gets hard to imagine where DR DOS as a bootloader would be saving anything that wasn't already optional.

On the other hand there are better options available. One could run DR DOS with DESQview to have a reasonably robust little multi-tasking environment. I seem to recall that DESQview and QEMM were eventually released as gratisware (non-free in the sense of libre, but at no cost).

One could also use eCOS which is free software supported by Red Hat (inherited as part of their aquisition of Cygnus, which was already GPL'd at the time, of course).

Red Hat, in January of this year (2004), announced its intent to transfer the copyrights in eCOS to the FSF.

eCOS has several advantages over DR DOS for embedded systems: it can be linked into usable configurations with as little as about 45K --- though adding support for TCP/IP, any filesystems, etc each adds to that). [I've heard that eCOS can be configured down to about 20K for some applications, but that's pretty damn slim!).

eCOS 2.0 was release just last year and there are still active development communities maintaining the toolchain (GCC and other Linux cross-development utilities) and BSPs (board support packages). While a MS/DR DOS based system would be hopelessly tied to the x86 architecture, while being unable to use most of the newer features of current PC hardware, eCOS will run on any architecture that you wish to port it to, and is actively supported by manufacturers of embedded systems hardware ("targets"). Also the eCOS APIs are designed to be relatively compatible with Posix, and I've read that ITRON APIs are also supported. (ITRON is a spec for a set of deeply embedded systems --- primarily used in consumer electronics and most popular in Japan)

Oh yeah! And eCOS optionally supports TCP/IP and soft real-time multi-tasking; which weren't included in DR DOS last I checked, not even optionally.

So, DR DOS for embedded systems only makes sense if you need to support existing software that was written to the MS-DOS APIs; and loading a Linux kernel under it makes no sense for embedded systems whether or not you can return back to the DOS prompt.

I mentioned eCOS because it was the first one that came to mind. There are dozens of other embedded systems available:

http://www.dedicated-systems.com/encyc/buyersguide/rtos/Dir228.html

Since "footprint" is claimed to be the primary attraction in this press release it seems interesting to read:

http://www.zdnet.com.au/news/business/0,39023166,20100710,00.htm

... though it doesn't actually mention any numbers for eCOS footprint. An article on eCOS and EL/IX (embedded Linux spec) covers this a little better:

http://www.us.design-reuse.com/articles/article2427.html

... and another that describes eCOS actually in use:

http://www.eetimes.com/story/OEG20000404S0024

... and one last one that gives yet more comparison:

http://www.elecdesign.com/Articles/Print.cfm?ArticleID=3787

From all of the preceding you'd get the impression that I hate DOS and love eCOS. Oddly enough that simply isn't true. I actually think MS-DOS was a fine little program loader in its day. I don't believe it was really an "operating system" in any modern sense of the term and I just can't see the relevance of this press release. As for eCOS, I have no experience with it. I've read a quite bit and would certainly recommend it over an MS-DOS/DR DOS approach to almost any new embedded systems project.

JimD