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