> The ROMfs code that has already been ported to ELKS is very good for this
> sort of thing, and I have set up the filesystem code so that a compiletime
> option can be specified to remove all the filesystem code related to
> writing to actual filesystems. This would allow a very small kernel to be
> created that could run binaries from a compact ROM filesystem. I think we
> should have the option of going further than this and removing the
> filesystem and block device code, and just loading binaries as described
> above so that ELKS can be used in systems where the memory is very tight,
> and only one or two binaries are required.
[<Simon Wood>]
For a completely ROM/RAM system we will need to support all file types,
otherwise we won't be able to log on (/etc/passwd) or use devices
(/dev/...).
I'll flick through the ROMFS code later this week.
>
> The minix executable format is quite well suited to being run in place on
> a
> ROM filesystem, providing as you say that filesystem is mapped into the
> main address space.
[<Simon Wood>]
Good
> One of the things I keep in mind is the Psion port. A filesystemless
> kernel
> would be easier to boot on the 3A initially until we have sorted out
> getting a RAMdisk image loaded.
>
[<Simon Wood>]
I'm still not confident about a 'loader' for the Psion, once the code is in
place it should work fine. I'm currently thinking that a small app could
load the code from a 'mother' computer over the serial port and then just
jump to into it. The same principle could be used to load any RAM/ROM disk.
