ELKS progress, and two or three other things

ELKS progress, and two or three other things

[Gregg C Levine]

Hello again from Gregg C Levine
First of all, I am pleased to see that there is considerable progress with
regard to the different issues with ELKS. All of them. And I am being
serious, not facetious, or anything related to that term. One of the two
other things. Dustin your parts came yesterday. Please ignore that message
that I sent as a complaint to you regarding them. At the time I did not know
how far away from here you were. I do know, and can appreciate the time
period the parts spent walking here.  I am also pleased regarding the
collection's contents. It makes a considerable addition to my parts box. And
now the other thing. Has anyone given any thoughts to making a port of ELKS
to run on an 80186 based system, as yet? I myself have that as the reason
why I was first involved in this, and then again involved. The other thing
is that I'd like to design an intelligent protyping system running ELKS, and
have it based on the 80186, rather then a 8086, or even an 80286. And that's
my collection of thoughts for now.
Gregg C Levine obiwanthejediknight@att.net
<This signature will be replaced, pending an approval from the Jedi Council.
>

Re: ELKS progress, and two or three other things

[Riley Williams]

Hi Gregg.

> First of all, I am pleased to see that there is considerable
> progress with regard to the different issues with ELKS. All of them.
> And I am being serious, not facetious, or anything related to that term.

I'm also glad to see the recent progress with both ELKS and dev86, and
am looking forward to testing the latest dev86 package both with ELKS
and with other software I've been playing with.

(Comments specifically for Dustin removed)

> And now the other thing. Has anyone given any thoughts to making a
> port of ELKS to run on an 80186 based system, as yet?

I've not given any specific thoughts to an 80186 based port of ELKS for
the simple reason that I don't have an 80186 based system to test it on.

However, I have thought about the more general problem of porting ELKS
to multiple different architectures, and feel that the layout of the
source files actually makes that considerably harder than it should be.
Here's some of the changes I'd like to see...

 1. Functions defined entirely in assembler language are ALWAYS
    found in *.S files, not in *.c files as many currently are.

 2. All *.c files that do not change from one architecture to
    another are moved away from the arch/i86 subtree. At the
    moment, most of the ELKS source is under that subtree.

 3. Anything relating to a specific processor is found under
    a directory specifically for that processor. This would
    move arch/i86/286pmode to arch/i286 for example.

 4. Anything specific to a particular hardware design is found
    under a directory specifically for that purpose. This would
    isolate PC_CLONE from SIBO for example.

 5. Anything that is the same for all ports is moved out of the
    arch subtree. At the moment, most of the ELKS source is
    found under the arch subtree, and this makes the idea of
    porting ELKS to something new appear harder than it should.

Here's an analysis of what currently exists, with some changes I would
make that involve moving entire directories elsewhere.

 Q>  2106  elks
 Q>   148  elks/Documentation/HTML
 Q>   134  elks/Documentation/HTML/FAQ
 Q>    12  elks/Documentation/HTML/Technical
 Q>    10  elks/Documentation/Images
 Q>    60  elks/Documentation/Text
 Q>     6  elks/Documentation/Text/Now-HTML
 Q>   256  elks/Documentation
 Q>   761  elks/arch/i86
 Q>    33  elks/arch/i86/286pmode		=> elks/arch/i286
 Q>    66  elks/arch/i86/boot
 Q>    21  elks/arch/i86/boot/tools
 Q>   305  elks/arch/i86/drivers
 Q>   139  elks/arch/i86/drivers/block
 Q>    23  elks/arch/i86/drivers/char/KeyMaps	=> elks/KeyMaps
 Q>   162  elks/arch/i86/drivers/char
 Q>     2  elks/arch/i86/drivers/net
 Q>    63  elks/arch/i86/kernel
 Q>    82  elks/arch/i86/lib
 Q>    27  elks/arch/i86/mm
 Q>    13  elks/arch/i86/sibo
 Q>   154  elks/arch/i86/tools
 Q>   763  elks/arch
 Q>   262  elks/fs
 Q>    59  elks/fs/elksfs
 Q>    59  elks/fs/minix
 Q>    20  elks/fs/romfs
 Q>   182  elks/include
 Q>    33  elks/include/arch
 Q>   147  elks/include/linuxmt 		=> elks/include/elks
 Q>     7  elks/init				=> elks/arch/i86/init
 Q>    54  elks/kernel
 Q>    12  elks/lib
 Q>     2  elks/modules
 Q>    66  elks/net
 Q>    12  elks/net/ipv4
 Q>    17  elks/net/nano
 Q>    17  elks/net/unix
 Q>   247  elks/scripts
 Q>    82  elks/scripts/lxdialog
 Q>    36  elks/video
 Q>    23  elks/video/ansi
 Q>    11  elks/video/vt52

I would like to see ELKS made much easier to port than it currently is,
and also less susceptible to a change in one port stopping other ports
from working, but it's not something I could do on my own.

> The other thing is that I'd like to design an intelligent protyping
> system running ELKS, and have it based on the 80186, rather then a
> 8086, or even an 80286.

I'd love to see that as well.

> <This signature will be replaced, pending an approval from the Jedi Council>

That is gramatically incorrect: the word "an" should be removed.

Best wishes from Riley.

Re: ELKS progress, and two or three other things

[Alan Cox]

On Sat, 2002-08-03 at 02:09, Gregg C Levine wrote:d
> now the other thing. Has anyone given any thoughts to making a port of ELKS
> to run on an 80186 based system, as yet? I myself have that as the reason

It does run on a PC compatible 80186 box. That bit I do now know.