> > ELKS is not that bloated to be honest. It's got a few areas that would
> > probably save a chunk of memory if fixed but the basic architecture is
> > pretty sound including basic 286 mode support.
>
> Nice! I had an impression that it was severely constrained by the
> 64k limit for itself, which would make it very hard to extend the
> functionality. Of course a part of the problem is the compiler
> efficiency limitations.
Code space there is a lot to save with a better compiler (eg the coherent
one) or bcc improvements and architectural changes here and there. Data
can be drastically improved by getting the wait logic to not put pointer
chains on the stacks. That would mean that you only needed to keep a few
instances of kernel stacks in the kernel map.
In fact some of the Fuzix ports go so far as to only have one kernel and
interrupt stack in kernel data, and to save it on a task switch out and
restore it on a switch in (if the arriving task is not the old one).
Small machines don't task switch a lot and the hard cases can be
restructured so that the wakeup intelligence is in the waker not the
sleeper (which is more efficient anyway)
ie you avoid the plague of what is effectively
while(!i_am_ready()) {
sleep_on(&foo);
}
type stuff in the big Linux kernel and instead of waking one queue you
end up doing
foreach(task_waiting_foo) {
if (task_is_ready(task))
wakeup(task);
}
in the context of the waker.
You can't always do that but most cases work.
More seriously though what do you need to find extra space to add ? The
network stack needs work but is mostly out of kernel mapping (and
probably should stay so as with 2.11BSD), the rest of the basic POSIX
infrastructure is pretty complete. The Linux kernel has grown over ten
times bigger since 1.2 days but I don't think it's added that much useful
to the core code.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
