From: Jody Bruchon <jody@jodybruchon.com>
To: Linux-8086 <linux-8086@vger.kernel.org>
Subject: Re: Where does ELKS need to go? (was: ELKS links broken)
Date: Sat, 19 Apr 2014 17:14:12 -0400 [thread overview]
Message-ID: <6f026c03-35f3-4dd3-ae51-9e4cf5bd0fcf@email.android.com> (raw)
In-Reply-To: <CA+E3k90Un0_MmDn7J1ueo4kCjqd0hB0igyHbX-UGBs2eQkfTcQ@mail.gmail.com>
>Thinking pie-in-the-sky .... I think that using it to teach elegant OS
>programming under resource constraints would be a great niche. It's a
>lost art, but one that has many "teachable moments" built in.
I think this is a good niche, but it will require that ELKS diversify beyond the 8086. I see the low-end 32-bit Intel platforms as a good target to begin with; while one can build a nice small Linux for use on a 486, Pentium, or even a VIA C3 or Transmeta Crusoe, such systems are grossly underpowered and somewhat memory-starved for modern Linux, glibc, X.org, gcc, and so on.
These systems are still relatively easy to run into and are regularly discarded. I have no working 16-bit PC-compatible hardware, but I have a closet slam full of 486 through P3 desktops and laptops.
It would be fantastic for ELKS to run on these platforms. I don't see the 8086/286 as a viable target anymore. To be a "teachable" platform, people need to be able to use it without scraping up rare vintage hardware. Linux abandoned 386 support somewhat recently due to the nasty batch of workarounds required to keep it working, and I think ELKS must follow suit in its own way.
I would like to have a kernel that can build and run on everything from 8-bit to 32-bit, with or without an MMU, and taking advantage of platform specific features where possible. Unfortunately, once again the problem comes back to the compiler; 8-bit processors tend to be very poor compiler targets with limited ability for position-independent code and often require bank switching to reach extra memory, 16-bit processors tend to have ugly segmented memory models, and finding a good compiler that targets even a fraction of them is no easy task; never mind generating quality code!
So we come back to the original problem: we either need a compiler or a change of target...
prev parent reply other threads:[~2014-04-19 21:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-05 1:12 ELKS links broken Michael Sklaroff
2014-04-18 19:26 ` Edoardo Liverani
2014-04-18 20:03 ` Where does ELKS need to go? (was: ELKS links broken) Jody Bruchon
2014-04-18 21:44 ` Edoardo Liverani
2014-04-19 16:45 ` Where does ELKS need to go? Harley Laue
2014-04-19 18:28 ` Royce Williams
2014-04-19 18:33 ` Jody Lee Bruchon
2014-04-19 20:38 ` Royce Williams
2014-04-19 22:29 ` Edoardo Liverani
2014-04-21 22:05 ` David Given
2014-04-19 18:07 ` Where does ELKS need to go? (was: ELKS links broken) Chad
2014-04-19 20:43 ` Royce Williams
2014-04-19 21:14 ` Jody Bruchon [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6f026c03-35f3-4dd3-ae51-9e4cf5bd0fcf@email.android.com \
--to=jody@jodybruchon.com \
--cc=linux-8086@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox