Regarding the Future of ELKS

Regarding the Future of ELKS

[Jody]

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.

* 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.

* 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.

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

Re: Regarding the Future of ELKS

[Royce Williams]

Jody wrote, on 5/5/2007 10:58 AM:
> 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 wish that I was enough of a coder to help.  Ironically, an OS that
can run on 8086 would be a great way to /learn/ to work on OS coding.
 In fact, I have been waiting for a usable ELKS so that I could begin
that learning process.

Unfortunately, I suspect that it's not the baby-talk-C work that's
needed in order to get the project moving again, but rather the
trickier work.

So maybe we could phrase the question another way: what prevents
people from contributing today?  Some ideas:


1. Cost of getting started to develop.  Even after reading the
archives and starting to study some of the code, I don't even know
where to begin -- and suspect that others are in the same boat.

Possible solution: If there was a wiki somewhere with a detailed
"State of the ELKS" reference page, so that someone could quickly
solve a problem or two as they had time, that might help.  Categories
like "Needs evaluation," "Needs testing," etc. might also be handy.
Such a reference might reduce the "startup cost" of contributing.


2. Cost of getting started to test/install/use.  I think that the FAQ
is good but needs to be improved.    A reference of known working
hardware would be good.  The "How can I help" part of the FAQ refers
to Outstanding Projects and Bugs sections of the main site, but I'm
not able to locate any such animal.

Possible solution: Make it a higher priority to create an installer.
Create a reference build that at least works enough to do development
on common systems.


3. Speed.  Compiling to test on an 8086 is maddeningly slow.

Possible solution: For true 8086-only emulation, find a good free
emulator, or contact someone who has a commercial one (emu8086.com,
for example) and see if they'll cut us a break on a pack of license
for core developers.

http://www.emu8086.com/
http://pcemu.sourceforge.net/
http://i8086emu.sourceforge.net/

Create some VMware/QEMU images or HOWTOs to make it easier to test
some code virtually and take advantage of newer processor speeds.


4. Bang for the buck.  Ultimately, I suspect that folks can get a lot
more mileage working on other things.  Once I get my Compaq Deskpro
Model 1 on the Internet, of what use will it be to me other than as a
hobby or for bragging rights?  Probably not much, unless I use to
improve my development skills.  I would certainly enjoy getting it
working, and would probably learn a lot ... but there are probably
diminishing returns thereafter.

Possible solution: Try to locate people who are enthused about the
work as a hobby.  Computer science departments might also be able to
locate students interested in cutting their teeth on a simpler OS.
Does anyone have any contacts in this area?


5. Critical mass.  Today, there's just not a lot of communication or
energy in the project (that's observable from outside, anyway).

Possible solutions: Modernize a bit.  Set up a wiki.  Take a head
count of people still on the list and ask them about their interests
and skill sets.  Divide up some of the outstanding tasks.


I would be happy to contribute some cash for a software license.  I
can also help with the wiki if we went that direction.  I'll also
start dinking around with some emulators to see what the possibilities
are.

Jody, if you think it's a good idea, could you encourage the
subscribers to post their interests and qualifications?  How many
subscribers are there?

Royce

-- 
Royce D. Williams                                - IP Engineering, ACS
personal: [first]@alaska.net                  - PGP: 3FC087DB/1776A531
work: [first.last]@acsalaska.net         - http://www.tycho.org/royce/

NOTICE REGARDING SENDING MAIL TO THE ELKS LIST

[Jody]

NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


DO *NOT* SEND A TO: OR CC: TO BOTH THE LIST AND A LIST

SUBSCRIBER.  THEY WILL GET IT TWICE AND REPLY WITH MESSAGES

NOT ENTIRELY UNLIKE THIS ONE.  THAT IS ALL.


                                    -- Jody --

Re: Regarding the Future of ELKS

[Gábor Lénárt]

On Sat, May 05, 2007 at 02:10:55PM -0800, Royce Williams wrote:
> 3. Speed.  Compiling to test on an 8086 is maddeningly slow.
> 
> Possible solution: For true 8086-only emulation, find a good free
> emulator, or contact someone who has a commercial one (emu8086.com,
> for example) and see if they'll cut us a break on a pack of license
> for core developers.

Or port ELKS to Linux user space, like UML. This helps testing the system,
though does not help to test hardware drivers for example: anyway it can be
a useful task both to make ELKS portable and test ELKS as a "normal" process
runnable on Linux.

-- 
- Gábor
-
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: Regarding the Future of ELKS

[David Given]

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

Royce Williams wrote:
>[...]
> http://pcemu.sourceforge.net/

PCEMU is mine, kinda; it's moderately accurate (will run DOS and most apps),
but the thing that makes it really useful for me is that it's got a largely
undocumented built-in debugger of about the same level of functionality as
DEBUG.COM. I usually find it easier to use this for machine-code level
debugging than struggling with gdb and qemu.

I did try ELKS on it a while ago and it did run, although there were some
timing loop issues.

...incidentally, since then I have also been working on the Amsterdam Compiler
Kit suite of compilers, and recently did a release; it the latest 6.0 now
contains support for 8086, 80386 and 8080 code generators. It's also been
hugely cleaned up --- I could add support for ELKS executables more or less
trivially, if anyone wants it (and can point me at the spec); the only bit
that's the slightest bit tricky is the syscall library. It supports genuine
ANSI C, and also Pascal and Modula 2 (also Occam 1 and Basic, should anyone
care)...

http://tack.sourceforge.net

- --
┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ───────────────────
│ "Parents let children ride bicycles on the street. But parents do not
│ allow children to hear vulgar words. Therefore we can deduce that cursing
│ is more dangerous than being hit by a car." --- Scott Adams
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGPc/2f9E0noFvlzgRAjAQAJ48kOIOiAOTsphuTnfR81zn6lVTvwCgozpp
a1UGFUphNDEN1zgOgUHJZd8=
=AHyt
-----END PGP SIGNATURE-----

-
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: Regarding the Future of ELKS

[Alan Cox]

> ...incidentally, since then I have also been working on the Amsterdam Compiler
> Kit suite of compilers, and recently did a release; it the latest 6.0 now
> contains support for 8086, 80386 and 8080 code generators. It's also been
> hugely cleaned up --- I could add support for ELKS executables more or less
> trivially, if anyone wants it (and can point me at the spec); the only bit

Not sure there is a spec per se but the ELKS system originally used minix
format binaries (indeed I've used minix binaries on it). The later binary
format fixes the minix 8086 design flaw where it puts the stack above the
data. Instead ELKS puts the stack at the bottom of the data in a space
size set at compile time. This allows brk() to work properly and avoids
the chmem mess Minix has.

If nobody ever did that fix to Minix it might be more useful to teach
minix how to handle sane binary layouts and real memory allocation than
ELKS hacking 8)

Re: Regarding the Future of ELKS

[David Given]

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

Alan Cox wrote:
[...]
> Not sure there is a spec per se but the ELKS system originally used minix
> format binaries (indeed I've used minix binaries on it). The later binary
> format fixes the minix 8086 design flaw where it puts the stack above the
> data. Instead ELKS puts the stack at the bottom of the data in a space
> size set at compile time. This allows brk() to work properly and avoids
> the chmem mess Minix has.

According to the ACK source, Minix uses PC/IX a.out files! I never even knew
the standard had a name. Minix i86 appears to use CPU 4, which matches the
ELKS a.out.h file.

Is there any way to distinguish between a Minix binary and an ELKS binary?

(Interestingly, putting the stack at the *bottom* of the data is exactly what
I did with the CP/M platform. In my case it was to make it easier for brk() to
tell where the end of the program area was. Strictly it shouldn't be necessary
for any platform to have a defined position for the stack; parameters can be
passed to the executable via registers, and then setting up the stack can be a
pure user-mode thing. I don't know if anyone actually does this, though.)

[...]
> If nobody ever did that fix to Minix it might be more useful to teach
> minix how to handle sane binary layouts and real memory allocation than
> ELKS hacking 8)

Can't comment on binary formats, but apparently someone is working on a real
VM for Minix 3, which should allow brk() to be actually useful. I'm hoping
that I can wait until then before porting the ACK's new build system...

- --
┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ───────────────────
│ "Parents let children ride bicycles on the street. But parents do not
│ allow children to hear vulgar words. Therefore we can deduce that cursing
│ is more dangerous than being hit by a car." --- Scott Adams
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGPgyzf9E0noFvlzgRAhFCAKC6g/9TRkTvt8/Ed7a08LOyb7WbWACfetkH
wwapxf263425OWTpkevHxO8=
=pLwQ
-----END PGP SIGNATURE-----

-
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: Regarding the Future of ELKS

[Alan Cox]

> (Interestingly, putting the stack at the *bottom* of the data is exactly what
> I did with the CP/M platform. In my case it was to make it easier for brk() to
> tell where the end of the program area was. Strictly it shouldn't be necessary
> for any platform to have a defined position for the stack; parameters can be
> passed to the executable via registers, and then setting up the stack can be a
> pure user-mode thing. I don't know if anyone actually does this, though.)

Not in Unix because of the rlimit rules for stack size, and also even
more importantly because you could in theory take a signal on your first
instruction, which would need to stack stuff.

> Can't comment on binary formats, but apparently someone is working on a real
> VM for Minix 3, which should allow brk() to be actually useful. I'm hoping
> that I can wait until then before porting the ACK's new build system...

Doesn't need a VM, basic swapping will do, thats all ELKS has. It uses
the V7 Unix algorithm

	if can grow data segment
		grow it
	else
		swap out
	endif

(and it'll swap back into a suitable space, as well as the swap tending
to punish memory hogs)

Re: Regarding the Future of ELKS

[Mario Frasca]

On 2007-0505 14:58:51, Jody wrote:
> I can see many compelling reasons to drop ELKS entirely or
> shift it away from the 80(2)86-oriented platform [...]

> 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!

hi Jody,
hi list,

I have done something in the past with ELKS, worked on ls and the init
procedure, I think...  

in the end, ELKS did not result 'usable' for me, all I wanted to use there
was an editor, but I did not manage to find nor port/compile anything.
I tried during a few weeks, then gave up.  without an editor, I would not
know what to do with a PC.  at the time I tried to use an old Amstrad
(V30 based, 8086 compatible), just for the fun of it, and also because
it had a very nice keyboard.  the system is still there, still working,
but still without an editor.

What other alternatives can I go?

- buy a better laptop, 386 based, and use linux?  minix?  freebsd?
- use dos...
- use an other operating system (which one?)
- port a minimal editor to ELKS...

but these are the alternatives to my problem, which is "running
something on an old 8086 that would allow me to edit text"...

I am sure that ELKS can be defined 'usable' in other ways, this is just
my own interpretation.

looking on the elks website, I miss something, or it's too late and I
can't find it.  it states why (create a linux-like kernel), but then this
is not the whole story, is it?  we do want to use the kernel.  maybe we
could use the sourceforge tracker to keep track of what has to be done.
in the website I would also put more and more explicit links to the
tracker, so that also the occasional browser WILL check it...

ciao,
Mario

-- 
Never, under any circumstances, take a sleeping pill 
and a laxative on the same night. 

Re: Regarding the Future of ELKS

[Hans]

Hi Jody,

I am sure there is still live in ELKS but unless it is picked up by a very 
enthusiastic experienced hacker with lots of spare time and experience I 
think ELKS will remain a dormant project (like so many of sourceforge). 
Unfortunately my hardware is not PC/XT compatible which means that I need to 
understand all the nitty gritty stuff. When I looked at the source code I 
quickly came to realise that this is an un-doable project for me. This was 
not helped by a custom C compiler and non-flexible development environment 
so in the end I gave up and became one of the many(?) low-active lurkers on 
this list :-)

I will remain subscribed to this list and hope that one day ELKS will burst 
into life with a vengeance :-)

Hans
www.ht-lab.com

----- Original Message ----- 
From: "Jody" <jbruchon@nc.rr.com>
To: "ELKS" <linux-8086@vger.kernel.org>
Sent: Saturday, May 05, 2007 7:58 PM
Subject: Regarding the Future of ELKS


> 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.
>
> * 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.
>
> * 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.
>
> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Regarding the Future of ELKS

[Luis A. Montes]

-----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@vger.kernel.org
> 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-----

Re: Regarding the Future of ELKS

[Mario Urban]

> 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.
>

There is no good documentation available.
A WORKING documentation-project for ELKS is needed..

> * 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.
>
Does that make Sense?
Minix, Linux are available for 32bit systems.
Do we need another one? I dont think so.
But there is no "up-to-date" system which you can use on a 8086-80286.

> * 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.
>
First step should be to look for a good sponsor.
The entire project should be hosted and maintained by a greet Linux-Player.
Ubuntu comes to my mind...
Someone should ask them...
The project is little, it needs not many ressources compared to a 
Linux-Distro.
I too remember that the Elks-Website was not updated for years..
No good sign for a project looking for developers...

> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>