Re: We have a whole new ton of goodies to investigate...

[u-vpoa@aetey.se]

On Mon, Apr 27, 2015 at 02:35:54PM +0100, Alan Cox wrote:
> > One extra thing I would appreciate in the kernel is of course the support
> > for code segment switching, making several-times-64k code sizes practical.
> 
> If you are willing to accept violating the standard when comparing
> function pointers, and you are willing to pull a couple of other stunts
> then that is actually trivial. You generate far calls for all inter
> function calls, and also tell the compiler to assume the arguments are 2
> bytes further up the stack.

This implies that the compiler must be "more-than-16-bits-aware" and
produce a larger code.

I like the trampolines approach, when you have all pointers, including
the function ones, as 16 bit, and you can use any compiler.
The address of a function is the same in all segments, which is
the address of its linker-generated trampoline. There is some size and
run time overhead but only at inter-segment calls and at function pointer
dereferencing. This needs only support in the linker and in the kernel
(like "ld -m" on Venix/86).

> I think the Coherent compiler can also do it "properly". It can for 286
> anyway, I've not been through the 8086 version in enough detail to figure
> it out.

Wonder how hard it were to port it to run under ELKS.

> > this can easily push the limits both for the code and the data, if not
> > putting the drivers into different address spaces or strictly limiting
> > the number of simultaneously usable drivers)
> 
> On a box with very little memory it makes little sense to include drivers
> you don't need!

Oh yes, but you can happen to have lots of various connected hardware _and_
many times 64K memory which would make this argument void.

> If you compare it with 4BSD or System 5 on the syscall level I'd say yes.

Nice!

> It may well need bug fixing and structural work for size but it's only
> really lacking the relatively modern syscalls, most of which are
> inappropriate and the others could I guess be added but none of the small
> userspaces use them - openat etc.

Yes.

> The networking side lacks IPv6 and a lot of other bits, but that's
> outside the core, and could probably be reworked to keep the current
> kernel bits pretty much as is and adopt lwip for the stack.

+1

Rl