[ELKS] Should we resume ELKS development?

[ELKS] Should we resume ELKS development?

[jody]

Greetings, everyone. As you may be aware, a long time ago I was "handed the
keys" to the ELKS project.  I'd like to discuss the possibility of continuing
development.
 
I have seen a reference to the RTOS "NuttX" and discovered an exchange in which
Gregory Nutt indicated ELKS and NuttX were too different in their goals.
Additionally, NuttX has no i86 port, and as we all know, the hardest steps are
usually the first ones.  Because of these factors, I am hesitant to say "abandon
ELKS and develop NuttX instead."  I am, however, left with the question of
duplicated efforts: what operating systems exist that do the same general thing
as ELKS, and how much overlap is there?  How "far" are they, in terms of overall
usefulness?
 
I'm also becoming curious about what it takes to retarget the bcc compiler for
other 8-bit and 16-bit processors (i.e. MOS 6502/65816, Zilog Z80/Z8000,
Motorola 6800/68000), particularly since there is evidence in the current Dev86
bcc source code where the original compiler supported a Motorola 6809 target
that has been subsequently removed.  While ELKS is currently very i86-specific,
it could prove very beneficial to open up the ability to target more platforms.
 
Finally, I'd like to ask everyone who still reads this list: considering it is
the year 2011, and 8086 machines were superseded more than 20 years ago, should
ELKS development continue at all, and if so, what direction should it take?
(The retargeting suggestion is part of this question.)
 
I have taken the liberty of downloading as much ELKS-related code and materials
as possible, and I am prepared to set up a Git repository for ELKS if enough
interest in such a thing exists.
 
Thanks in advance, and I'm looking forward to hearing from everyone once more.
 
Jody Bruchon
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ELKS] Should we resume ELKS development?

[Gregg Levine]

On Mon, Apr 11, 2011 at 1:51 AM, jody@jodybruchon.com
<jody@jodybruchon.com> wrote:
> Greetings, everyone. As you may be aware, a long time ago I was "handed the
> keys" to the ELKS project.  I'd like to discuss the possibility of continuing
> development.
>
> I have seen a reference to the RTOS "NuttX" and discovered an exchange in which
> Gregory Nutt indicated ELKS and NuttX were too different in their goals.
> Additionally, NuttX has no i86 port, and as we all know, the hardest steps are
> usually the first ones.  Because of these factors, I am hesitant to say "abandon
> ELKS and develop NuttX instead."  I am, however, left with the question of
> duplicated efforts: what operating systems exist that do the same general thing
> as ELKS, and how much overlap is there?  How "far" are they, in terms of overall
> usefulness?
>
> I'm also becoming curious about what it takes to retarget the bcc compiler for
> other 8-bit and 16-bit processors (i.e. MOS 6502/65816, Zilog Z80/Z8000,
> Motorola 6800/68000), particularly since there is evidence in the current Dev86
> bcc source code where the original compiler supported a Motorola 6809 target
> that has been subsequently removed.  While ELKS is currently very i86-specific,
> it could prove very beneficial to open up the ability to target more platforms.
>
> Finally, I'd like to ask everyone who still reads this list: considering it is
> the year 2011, and 8086 machines were superseded more than 20 years ago, should
> ELKS development continue at all, and if so, what direction should it take?
> (The retargeting suggestion is part of this question.)
>
> I have taken the liberty of downloading as much ELKS-related code and materials
> as possible, and I am prepared to set up a Git repository for ELKS if enough
> interest in such a thing exists.
>
> Thanks in advance, and I'm looking forward to hearing from everyone once more.
>
> Jody Bruchon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Hello!
Let's let ELKS continue in its present state for a while longer. In
all actuality 8086 based systems still turn up. For example those
crazy people at Microsoft still sell DOS, for embedded uses only as it
happens, but it is still there.

Which is a fact which I commented on at an event held at their NYC
offices last month, and got awarded a grouchy and bored XBOX360 for my
comments. (They announced the roll out of the seventh version of
Windows Embedded at it.)

The subject also surfaced at an event held at their NJ offices about a
year earlier.

I've been auditing an embedded version of DOS from a now defunct
company for the past year and while I am making no progress it happens
that I am very close to assembling a target for it.
-----
Gregg C Levine gregg.drwho8@gmail.com
"This signature fought the Time Wars, time and again."
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ELKS] Should we resume ELKS development?

[Harley Laue]

Sorry for the late reply, I had meant to do it earlier than this but
lost track of time.

jody@jodybruchon.com wrote:
> Greetings, everyone. As you may be aware, a long time ago I was "handed the
> keys" to the ELKS project.  I'd like to discuss the possibility of
> continuing development.

Excellent. I personally have always liked small OS's and kernels
because their design is to keep it small. Thus, allowing single
developers the possibility to understand all parts of the kernel (try
that with the current Linux code base. :) )

> I have seen a reference to the RTOS "NuttX" and discovered an exchange in
> which Gregory Nutt indicated ELKS and NuttX were too different in their
> goals. Additionally, NuttX has no i86 port, and as we all know, the
> hardest steps are usually the first ones.  Because of these factors, I am
> hesitant to say "abandon ELKS and develop NuttX instead."  I am, however,
> left with the question of duplicated efforts: what operating systems exist
> that do the same general thing as ELKS, and how much overlap is there?
> How "far" are they, in terms of overall usefulness?

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.

> I'm also becoming curious about what it takes to retarget the bcc compiler
> for other 8-bit and 16-bit processors (i.e. MOS 6502/65816, Zilog
> Z80/Z8000, Motorola 6800/68000), particularly since there is evidence in
> the current Dev86 bcc source code where the original compiler supported a
> Motorola 6809 target that has been subsequently removed.  While ELKS is
> currently very i86-specific, it could prove very beneficial to open up the
> ability to target more platforms.

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.

> Finally, I'd like to ask everyone who still reads this list: considering it
> is the year 2011, and 8086 machines were superseded more than 20 years
> ago, should ELKS development continue at all, and if so, what direction
> should it take? (The retargeting suggestion is part of this question.)

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 have taken the liberty of downloading as much ELKS-related code and
> materials as possible, and I am prepared to set up a Git repository for
> ELKS if enough interest in such a thing exists.

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 :)

> Thanks in advance, and I'm looking forward to hearing from everyone once
> more.
> Jody Bruchon

-- 
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying convention use in e-mail clients?

Re: [ELKS] Should we resume ELKS development?

[Jody]

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

Re: [ELKS] Should we resume ELKS development?

[Mario Frasca]

On 2011-0510 14:44:19, Harley Laue wrote:
> jody@jodybruchon.com wrote:
> > I have taken the liberty of downloading as much ELKS-related code and
> > materials as possible, and I am prepared to set up a Git repository for
> > ELKS if enough interest in such a thing exists.
> 
> 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 :)
> 
> > Thanks in advance, and I'm looking forward to hearing from everyone once
> > more.
> > Jody Bruchon

hi here,
I'm an old-time contributor to parts of ELKS.  not the kernel, though.
Harley, when you say git, you don't mean github?  
(I like git and the 'fork' freedom it gives, and I like github).
I see this one on sourceforge:
git://elks.git.sourceforge.net/gitroot/elks/elks

as on github, one just needs an account to start a own fork.

sounds VERY useful, and as for "official", I would let practice show
which is the leading line.  a few years ago some old contributors also
tried to revive the project, but after some discussion somehow we all
dropped the idea.  maybe had to do with difficulty to get write access
to the repository, I can't remember.  had git existed at the time,
maybe things could have moved better.  let's see who is still around!
my PPC640 is still waiting (but diskettes have become rare)!  :)

MF

-- 
lapide al cimitero: 
  qui giace un ateo 
  vestito di tutto punto 
  senza un posto dove andare.

Re: [ELKS] Should we resume ELKS development?

[Harley Laue]

On Sun, May 15, 2011 at 4:53 AM, Mario Frasca <mfrasca@zonnet.nl> wrote:
> On 2011-0510 14:44:19, Harley Laue wrote:
>> jody@jodybruchon.com wrote:
>> > I have taken the liberty of downloading as much ELKS-related code and
>> > materials as possible, and I am prepared to set up a Git repository for
>> > ELKS if enough interest in such a thing exists.
>>
>> 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 :)
>>
>> > Thanks in advance, and I'm looking forward to hearing from everyone once
>> > more.
>> > Jody Bruchon
>
> hi here,
> I'm an old-time contributor to parts of ELKS.  not the kernel, though.
> Harley, when you say git, you don't mean github?
> (I like git and the 'fork' freedom it gives, and I like github).
> I see this one on sourceforge:
> git://elks.git.sourceforge.net/gitroot/elks/elks

It was just a personal clone on my personal server.

> as on github, one just needs an account to start a own fork.

Honestly, I think Github and Gitorious handle Git repos much better
than Sourceforge if you have a project which might get enough interest
to branch out. Last I checked, sourceforge didn't have anything
similar to the "fork" feature these services have.

> sounds VERY useful, and as for "official", I would let practice show
> which is the leading line.  a few years ago some old contributors also
> tried to revive the project, but after some discussion somehow we all
> dropped the idea.  maybe had to do with difficulty to get write access
> to the repository, I can't remember.  had git existed at the time,
> maybe things could have moved better.  let's see who is still around!
> my PPC640 is still waiting (but diskettes have become rare)!  :)

Hopefully this new discussion will pique some peoples' interest to
take up work on the project again. The ability to collaborate and
create your own branches/forks may help (or may not, but it couldn't
hurt right?) :)
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html