Re: Definitive tree
On Mon, Jun 19, 2000 at 12:02:41AM +0100, Alan Cox wrote: : I think I've figured how to : sort some of the stack handling stuff out and get some of our data space : back. You're not thinking of backtracing stack addresses, are you? The last release can be found here: ftp://ftp.ecs.soton.ac.uk/pub/elks/elks-0.0.83/ and the source is now stored under CVS at sourceforge: http://sourceforge.net/project/?group_id=3232 Let me know if you have a username on sourceforge, and I will add you to the project. No. Something much simpler. The idea being to get into a state where there is nothing on the kernel stack needed when a task is not in RUN state.. ie replacing the wait queue/select stuff with a V7 like setup. Is this in some way related to your idea of moving the structure required from the kernel stack to the task structure? User space Im very tempted to rebuild the system with the stack at the base of the data segment, although that would prevent chmem working without relocation maps on load. It trades it for the ability to truely grow process space once you have swap I was working along these lines when I got distracted by other things and stopped working on Linux-8086. I had implemented reading in the larger header version of the minix format executable, and using one of the fields in the extended header as the size of the stack below the datasegment. I think this code had been developed to point where it worked, but building binaries that it would load required extra compiler flags, and hacking the header with a binary editor. Al
Re: Definitive tree
and the source is now stored under CVS at sourceforge: http://sourceforge.net/project/?group_id=3232 I'll grab the sourceforget copy and probably send you diffs. (I dont have the local bandwidth to fight cvs) Is this in some way related to your idea of moving the structure required from the kernel stack to the task structure? Yes Alan
Re: Definitive tree
I've gotten pretty familiar with the linker, let me know if you need a hack. Otherwise, my memory says that we've got enough info in the current header to put the stack below the data, providing the linker will change the beginning data offset to the max stack size. We can already build binaries for this format. What we cant do is build ones you can chmem. I now have an ELKS that is a bit cleaner (not a lot), has my new wait queue code working and I've written but not tested the back end for the swapper. It needs someone strategy code and syscalls. Right now only the bios driver will get swapping right since I had to add req-rq_seg so I can swap stuff without going via buffer cache - also means I guess we can write directly from the L2 buffer cache. Alan
Re: Definitive tree
: I think I've figured how to : sort some of the stack handling stuff out and get some of our data space : back. You're not thinking of backtracing stack addresses, are you? No. Something much simpler. The idea being to get into a state where there is nothing on the kernel stack needed when a task is not in RUN state.. ie replacing the wait queue/select stuff with a V7 like setup. User space Im very tempted to rebuild the system with the stack at the base of the data segment, although that would prevent chmem working without relocation maps on load. It trades it for the ability to truely grow process space once you have swap Alan
