>
> > I think the choice for embedded OS really depends on what you like
> > to do. Of course you are writing the firmware for a coffee maker,
> > it would be silly to use an UNIX-like OS. Then you could probably
> > write some assembly code to do what you want. But if you are doing
> > some Internet appliance with a browser, e-mail, TCP/IP stack, PPP
> > or SLIP and a file system, than one would want to take advantage
> > of the wealth of free software out there written for UNIX. Then
> > the choice is clearly between QNX and LINUX.
>
> And {Free|Net|Open}-BSD and a few others.
>
> > I have used both QNX and Linux in embedded applications. QNX is
> > excellent robust OS for embedded applications. The main advantage
> > of QNX over Linux is its ability to reboot without corrupting the
> > file system and its modularity, as well as Micro-kernel
> > architecture. But the size advantage is really not significant. A
> > QNX kernel with support for networking, TPC/IP, file system
> > etc. comes to about 500K. Not much different from Linux. When you
> > consider the cost of QNX, as well as the non-standard Watcom
> > compiler, the choice is not that clear.
>
> It's pretty rare to corrupt a Linux filesystem by pulling
> the plug on it. There's a mount option for synchronous
My observation has been that it is very rare, but not impossible. We
routinely cut the power of a large number of Linux boxes. In three
years of this, I have twice seen a situation where the default RedHat
startup fsck sequence couldn't recover things and dumped the sysetm
into a single-user shell. The systems were recovered without problems
from there. The script can be tweaked to do a fsck -y no matter
what if you prefer.
Just remember to do sync (three times for the superstitious) if you
have a situation where you are modifying a lot of files and then expect
to have a power shutdown directly after this.
> I/O that reduces the chances even more (and exacts a
> corresponding cost in fs performance).
>
> It's also pretty easy to construct an initrd and have a
> script/program that automatically rebuilds a filesystem if
> it does get corrupted. (You can store a 'tar.gz' file on an
> unused partition and restore whole filesystems from there,
> among many options).
>
Exactly. You can fit enough utilities on a single-floppy system
(see bootdisk howto) to mke2fs the active partitions, re-initialize
swap, and untar the images from the spare partition. Remember to
set the umask to 000 before you untar.
One note. I couldn't get fdisk to run from a script.
> It's also pretty easy to implement and use custom
> filesystems for Linux. You have plenty of examples to work
> from.
>
>
For you, perhaps... Still there are ROMFS type things.
-- cary
