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

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

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

For function pointers (eg in arrays and structs) the code generates a
little stub function which saves the bank calls the function and returns,
so that a near call to the stub function goes to the correct far function
and back. Again on 8086 that's much easier to generate as it's basically

	func_stub:
		call far func
		retf

and all the calls to a function pointer then effectively end up as

	call far STUBSEG:ax

or similar depending how the compiler chooses to construct them.

Strictly speaking you can do maths on function pointers and cast them
about in odd ways so a function pointer ought to be 4 bytes, so a void *
needs to be 4 bytes and it all goes to hell, but in the real world the
above works even if it offends the more anal members of standards
committees.

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.

> (Also there is always a desire for support of additional hardware,
> 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!

> This aside, do you say that the ELKS kernel is pretty much complete
> nowadays, and that it is only user space which needs fixing to make the
> system usable?

If you compare it with 4BSD or System 5 on the syscall level I'd say yes.
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.

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.

Alan