Ah, let's see if I can come up with some useful input tonight :)
NuttX is interesting and the main developer seems really nice/helpful.
His main concern about differing priorities was the fact that NuttX is
designed to be embedded and thus doesn't care as much about security
because the OS is embedded in the single running application (most of
the time at least.) With that in mind, ELKS may still end up being
more useful if the target. So if it's important for ELKS to continue
to use some processor features like user/supervisor address modes (I
think 286 has a protected mode option available), then ELKS is still
viable here. As far as overlap, there's some overlap in that they're
both (for the most part) implementing the POSIX OS interface in the
kernel. There are many other small and embedded OS's (one of my
favorites is KallistiOS for the Dreamcast) but I don't really know
/that/ many that still target< 386's.
Most small (8/16-bit) and embedded designs don't have user/supervisor
mode nor an MMU. NuttX is an RTOS; ELKS isn't trying to be an RTOS, so
there is already that fundamental difference. (Linux isn't an RTOS at
heart either, though it has been adapted to be closer to realtime, it
does just fine without it.) The problem that I see is that there is no
"Linux for small CPUs" out there: while Linux has been ported to
practically every 32+ bit architecture of significance, and therefore
provides a common system on which to build software for almost every 32+
bit system in existence with sufficient resources, no such thing exists
for computers smaller than 32-bit. The biggest reason I see for this is
a distinct lack of a common compiler, which leads into the next part.
Is it going to be easier to make the Elks source less BCC specific or
to add targets BCC? For instance, SDCC has targets for Intel 8051,
Maxim 80DS390, Zilog Z80 and the Motorola 68HC08. Either way it may
end up being a significant amount of work.
Neither SDCC nor BCC target all of the major processors that the most
widespread old computers are based on, specifically (but not necessarily
only) the MOS/WDC 6502/65816, the Zilog Z80, and the Intel 808x/80x86
series. There seems to be no shortage of compilers, but most of them
target one architecture, while the others don't target enough. If I
wanted to run an OS like ELKS on a PC/XT, Commodore 64, Apple IIgs, and
TRS-80, I'd naturally have to be able to port it to all of those
processors first. Trying to write code that builds on bcc, SDCC, and
cc65...well, I'd rather drop an anvil on my foot. Since I saw that bcc
had the underpinnings of a 6809 port in its dev86 source code, plus ELKS
is already written for that specific compiler, it came to mind as a good
starting point: retarget bcc, and BAM, compiler problem solved plus
portability rewriting is less difficult (since ELKS wouldn't need
rewriting for a different compiler).
I think the 8086/8186/8286 targets should be preserved, but it might
be worthwhile to evaluate some other options. For instance, if the
code could become less BCC specific everywhere it makes sense (or
should I say, everywhere but arch/i86) it may then be possible to have
an ARM or AVR port with GCC or a Z80 port with SDCC (perhaps with
support for the C128...) Or perhaps I'm just dreaming at this point :P
If ELKS could be built for three major targets (8086, Z80, 6502) then
ELKS could potentially run on the vast majority of home computers that
came out in the late 70s and the 80s. Since banking and memory
management varies wildly from one computer to the next (C128 vs CBM-II
vs 80286), a generic memory management framework would be needed, but
adding such a framework then opens the door to run on targets that Linux
has long since forgotten; namely, the 80386, which glibc does not
compile for anymore, and 386/486 machines with less than 8MB of RAM
would also make nice high-end targets. As Linux loses usefulness for
the smallest and oldest machines due to natural bloat, ELKS can pick
those machines up.
Personally I did a git cvsimport almost two years ago (not much really
came from that though), but an official Git repo for some of the
current CVS trees would be even more ideal :)
I'd be happy to set up a SourceForge git repo. Also, for those who are
wondering, I have full access to the ELKS project on SourceForge, which
means I have SSH etc. and can change the website and everything else as
needed...and I am more than happy to do it. I'm just looking for the
direction that we go from here.
Jody Bruchon
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
