Czech writes:
>
> To Al Riddoch,
> I was just wondering how big the code for
> swapping is on a linux like Red Hat was. I would like to know
> because I want to put swap space support for ELKS. I'm not very
> good at C programming but I was wondering if it is possible to
> make swap space that didn't require a partition. i am not sure
> if you have heard of the DosLinux or not but it is a linux that
> doesn't require a partition and works on DOS. It has swap space.
> I know we would have to sort out some problems that it might
> create because of the code needing a 386 and above, but I hope
> it is possible. The think i love about ELKS is it is so easy to
> use. You don't need to partition your hard drive or install it.
> i just want to keep it that way and yet keep it small, (I have
> an old XT with a 10 Meg hard drive). Partitioning the hard drive
> would in my opinion would make it less attractive to other
> users. It is so easy to just place the disk in the floppy drive
> and turn the computer on.
>
Swapping under ELKS is going to have to have a fundamentally different
approach from Linux. Linux runs on a protected mode architecture with full
memory management which means that all memory adressing is virtual, and if
a page of RAM is accessed which does not currently exist in real memory,
to process is stopped and the page is copied in from disk. We cannot do
this in ELKS as there is no memory protection. All we can do is swap out
entire processes if they are not currently running. This can be done in two
ways, as each process has two blocks of memory allocated. Firstly the code
segment can be deallocated, but does not need to be swapped out as it can
be re-fetched from disk at any time from the executable file. The code
segment is totally unchanged at runtime. This feature is already exploited
because we have the ability to run two or more copies of the same binary
with only one code segment allocated. (See the code in fs/exec.c that loads
the code segment for details.
The second possibility is to add the feature of saving the data segments
of processes to disk. You could do this the conventional way by having a
partition, but there are other options. One is to create an inode on the
root partition which does not existas a real file, but in which blocks can
be allocated and used to store process images. Another ELKS feature you
may wish to exploit is that you do not need to save the whole data segment.
The layou of the data segment is as below:-
Address:- 0x0 t_endbrk t_endstack t_begstack
_______________________________________________________
| | | | | |
| data | bss | heap | | stack |
| | | | | |
|________|_______|________|____________|______________|
The unlabelled section in the middle is not used, and is frequently a large
proportion of the data segment.
Al
