Re: some Elks suggestions

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

On Fri, 2003-02-28 at 08:44, Alfonso wrote:
> Uh-oh. I'm looking at ELKS sources: IMHO it's a mess (big mess). I'm

No offence taken, its kind of wandered and never really had a chief
evil dictator to lord over it

> 1)  ELKS architecture should contain a "Plain" mode, which ignores 
> everything PC-related (and even any check for Sibo, PC, MCA, etc);

Mainstream linux nowdays (2.5.x) actually has mach-pc mach-pc9800
mach-voyager etc..

> 3)  I don't understand why the kernel stack has to be 64k-sized. Aren't 

The kernel stack is a lot smaller than that. We have one stack per
process however. Don't be fooled by the segment ranges, the kernel 
just has SS=DS for the same range.

> 4)  I don't understand why we should use only INT 0x80. Using 128 

Because Linux did, because Minix did. 

> 5)  (this one means "I may seem drunk"): did anyone ever thought that a 
> number of classic library functions could be included in the kernel? 
> ELKS kernel has already str[n]cpy, atoi, str[n]cat, str[n]cmp, etc in 
> its source: add also a decent [s]printf and you will save lots (?) of 
> bytes on every final executable. Yes, the main goal for every version 
> is "reduce code size", but... what about reducing codesize for a bunch 
> of executables? (will the dynamic-linking of C libraries save space 
> and speed and work more than this weird solution?)

You'd need to deal with far data and swapping. It gets horrible.

> - you can stay in little (little, little, little) RAM;

Its not clear how much you win, plus systems like UZI and OMU aready 
exist in C and are tons smaller than Linux

The biggest thing Linux 8086 needs right now imho (other than someone to
act as a full time dedicated maintainer) is the block layer being ripped
out. Right now we run a full Linux block layer designed to handle tons
of clever stuff that simply isnt valid on a system without megabytes of
cache and fancy I/O cards. That block layer costs a ton of space.

Alan