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