Your summary seems pretty good.
So its
384K base
64K window
64K window
(junk)
The segment switching for ramdisks is a non issue. We are either writing to
the code or data segment, so you an do large I/O's to the window boundary
using one segment for the target and one for the source.
That only gets vaguely hairy when you want to allow a smaller program to
be running across a 64K boundary. The mm handling for that kind of 'aligned
as we need within any 64K block' is fun stuff.
Another amusement here is that if you are prepared to accept 56K as the
maximum size for data, you can pull some very interesting stunts with the
kernel stacks, allowing for many more processes - and getting it to scale
per bank.
Basically you put kernel DS at
0x5000+8K
so it ends at
0x5FFF+8K
Now you put the kernel stacks at DS:E000 and you have 16 kernel stacks per
bank. As your banks grow your number of stacks and thus processes go- indeed
most of the task struct can go here too with a bit of care. This is how
V7 works on a PDP11 using the 8K segments they had. The so called
'u area' is all the crap a process needs that isnt needed when it isnt
running.
You'd need to change the wait queue code a little to handle this but not
much.
The memory protection is crude, but will catch accidental errors easily. You
can't catch deliberate attacks on such a box so why try.
Now how do the SSD's work 8)
Alan
