On Mon, May 11, 2015 at 10:27:08AM +0100, Alan Cox wrote: > > |<-------------------- 64K ----------------->| > > |<-------------------- 64K ----------------->| > > > > As many can overlap as it fits, with some extra margins for the stacks. > > The same works of course for combined code+data+heap too. > > Very clever! You stil then need to know the stack sizes and automatically > trap and move which means you need to call a helper on function entry > or alloca, but that's not difficult. Venix/86 did not use such helpers. I think it was reserving some reasonable amount for the stack and also was checking the stack pointer of the running process regularly for entering the "red zone" or something like that. This worked quite good provided that nobody put large arrays on the stack - the latter did not work and could kill the system. > It doesn't work in protected mode, which ELKS supports but for real mode > that would work beautifully. Indeed, why not. > The ELKS format basically turns the traditional arrangement around with a > predefined stack size rather than heap size, and stack at bottom, so the > heap can then expand upwards without mess. Apparently it preallocates too much for the stack in my case. Is there any means to tune this per binary? 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
