|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Ah, let's see if I can come up with some useful input tonight :)
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.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.
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).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.
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.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
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.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 :)
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