I'm no expert here, but following are my $.02:
: What sort of features are required for this type of system? It seems to me
: that a filesystem is not all that important with no storage. Are device
: drivers, interrupt handling and memory management the types of features
: required?
Having a kernel that can be shared with the std source would
of course be nice. So I think we need device drivers. The filesystem
stuff should be linkable just like the device drivers are.
In regards to interrupt handling, most of that should reside
in it's own arch-dependent file (much like it is now). If the interrupt
controller changes, we don't want to hack much more than one file.
: What type of API is the application code going to use? Is the UNIX system
: API any use at all?
:
Of course we'll want to be able to use the same development
tools, I would think. So it's quite convenient to have the libc code
and the sys vectors that are already built in the dev86 stuff. That
also allows the applications programmer to test stuff on linux as
well as on the SBC board.
: Are embedded applications run as stand-alone binaries, or do they get
: linked into the kernel and run as kernel threads?
With no filesystem, it's hard to "run" programs without
writing a "null" driver (kinda like the one you hacked a while back)
but seeing kernel threads would be nice. Then the std ELKS system
could also use them
Greg
