Re: Regarding the Future of ELKS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jody wrote:
> Hello everyone.  This is Jody, the current maintainer of the ELKS
> project.  I wanted to ask for everyone's opinion on what the future of
> ELKS should be.
> 
> I can see many compelling reasons to drop ELKS entirely or shift it away
> from the 80(2)86-oriented platform, including the following:
> 
> * No one works on ELKS.  Really.  I'm no C programmer, and apparently
> all the ones that COULD work on it have moved on to "bigger better
> things" in their lives.
I'm a C programmer and work in embedded systems, and I wanted to port
ELKS to other processors, but life just got in the way. And to be
honest, I haven't even really looked at the ELKS code yet.
> 
> * 8086/80286 cores are being dropped in favor of other platforms,
> including ARM, 386EX, Coldfire, etc.  While embedded Linux covers a lot
> of that territory, there is certainly some room for discussion of
> changing ELKS to be more portable and pushing it to those platforms. The
> minimalist approach to the ELKS kernel would make it far smaller than
> Linux and it could potentially compete with the likes of other smaller
> operating systems used in embedded applications, such as VxWorks.
Agreed. The main reason Linux, even uClinux, is not viable for some
microcontrollers is that both linux and uClinux are 32 bit OS's while
there are some 16 bit processors that could use a small footprint
Linux/POSIX look-alike. That's why I looked at ELKS in the first place,
I didn't have a 8086 in mind
> 
> * ELKS has not developed to a very "usable" stage yet.  There are a
> hundred different ways the project could go, but the original stated
> goals are quickly showing that they are not it.  Lack of interest in the
> project and limited ability to reuse the code are clear signs that
> something must change.
That's the main obstacle: it's going to be tricky to use code developed
for 32/64 bits microprocessors in the 16bit world. I wonder if the
endianes of the 8086 could be used to export an API that is compatible
with the 32 bit world while internally only using 16 bits. Big-endian
ports would have a bigger overhead.
> 
> To those of you who are still subscribed to this list: what do you think
> should be done?  I look forward to hearing your answers!
> 
> ~Jody
> -
> 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
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGPhSAJ4+d0CQL2bIRAkFCAKCT03tUCuJHByOwhuFUGIh71Y9v9wCg2RPV
CxDv6iyKvErBZ97C2QrDuCU=
=ggFe
-----END PGP SIGNATURE-----
-
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

[Index of Archives]     [Kernel]     [Linux ia64]     [DCCP]     [Linux for ARM]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux