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

Jody wrote, on 5/5/2007 10:58 AM:

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

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. 

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" <[email protected]>
To: "ELKS" <[email protected]>
Sent: Saturday, May 05, 2007 7:58 PM
Subject: Regarding the Future of ELKS

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

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

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

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)

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

Alan Cox wrote:
[...]

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

[...]

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

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

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.

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

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.

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

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.

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)

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

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.

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