Re: AW: [Fwd: Re: EDE - Personal Suggestions and Ideas]

Gábor Lénárt
2004-05-26T15:10:30Z

Re,

On Wed, May 26, 2004 at 03:17:47PM +0100, David Given wrote:
> On Wednesday 26 May 2004 14:06, Gábor Lénárt wrote:
> [...]
> > In a nutshell: segments should be considered as read-only values after
> > getting them from the system.
>
> Absolutely.

Well, I've wanted to write 'segment IDs should be' not just 'segments'.

> Basically, there are two routes you can go.
>
> * If you give your application access to segment IDs, then the kernel cannot
> change them directly (because it doesn't know where the application's put
> them). This means that on a 8086, your application is not relocatable, which
> means not swappable.

Or you can introduce a VERY ugly scheme: you should specify a pointer to
a 16 bit value when calling segment allocation/query. At return, kernel
will fill out the pointed word. Now, user app SHOULD ALWAYS load segment
from that memory word, instead of just loading it eg ES and use it forever
while the process run. Sure, very ugly, and a hard-to-track dead lock could
occure because a context switching would occure between loading segment ID
and use it. And it's VERY ugly and VERY complex as you can see. However,
in my 286OS (which source was destroyed several years ago, when my sister
tries to drink my computer with some cola ...) there was a signaling
mechanism and the kernel can notify application that it SHOULD reload
segment IDs and this signal is unblockable one. Sure, still ugly, but at
least we haven't got reload segment IDs every time ;-)

>
> * If you *don't* give your application access to segment IDs, then it's
> restricted to single code and data segments only. But because the kernel
> knows where the segment IDs are stored --- CS, DS, SS --- then the kernel can
> change them whenever it likes and the application doesn't even know.
>
> Advantages of the former: applications can be bigger. Disadvantages of the
> former: larger code. Slower code. Severe disadvantages on the 8086
> (basically, the system would be unusable). Less reliable; bad pointers run a
> higher risk of corrupting something.
>
> Advantages of the latter: smaller and faster. Much simpler. Much cleaner
> design. More functionality on the small systems. Poor-man's memory
> protection, making it more reliable. Disadvantages of the latter:
> applications can't be as large.
>
> I just don't think that the advantages of having multisegment programs
> outweigh the disadvantages. Anything that needs multiple segments should be
> restructured to run as multiple processes. Plus, I should point out that we
> don't have any compilers that support far pointers anyway...

OK, but let's see this from the view point of assembly (because it's low
level language). Inmagine that the process itself uses only some kbytes of
code and some kbytes of data, but the purpose of the program requires fast
access - let's say - 128K of data. If our program refeers that 128K data
in random order and it's a huge calulcation, you can't say broke the program
into two processes in this case ... But you can assume that its assembly
programmer say: OK, CS (code segment register) points to code segment,
DS (data segment register) points to data segment *AND* ES (extra segment
register) points to the ACTUAL user data segment. At startup the program
allocates two 64K wide segment and so get two segment IDs.

This *STUPID* example:

; user_seg_1 and user_seg_2 stores two segment IDs which points
; to two allocated segments at startup of the process
mov cx,CONSTANT
stupid:
mov es,[user_seg_1]
add al,es:[bx]
mov es,[user_seg_2]
add al,es:[bx+2]
loop stupid

Because this programs SHOULD access more data than 64K and it changes
segments VERY fast, you have no chance to implement this as two processes
just for a rule that one process should not have got multiple data/code
segments.

I think - as my example shows - it's not a problem of the kernel itself.
Instead we have got problem with the C language that it assumes easy and linear
access of the memory eg via pointers. But as you can see, in assembly you
can write quite usefull programs which almost hides the disadvantages of
the 64K segment limit rule (sure its somewhat slower because of the ES
loadings and es: prefixes, but we've done it folks, at least).

So there is no major kernel problem with multiple segments. So let's do it.
It's ANOTHER question that writing a multiple segmented user space program
in C would be HARD, but it's not the problem of the kernel ... We have at
least give the possibility to be ABLE to do this in user space, of course
you mustn't use it anyway if you don't want it ;)

So my ONLY though with this long novel ;-) -> at least we should provide
the possibility for multi segment processes ... Sure, at startup process
shoulde REQUIRE kernel for multi segment mode. In this way there is no
slowdown or other resource bottleneck of this scheme if we don't want it.
But if we want it, kernel prepares eg the above described signaling
machanism and other stuffs I was talking about.

> PS. Please don't cc me! I'm subscribed to the mailing list! I don't need more
> copies of the messages!

Hmm, sure, I've got similar thought as well at first, but I got the idea
that here everyone CCs everyone ;-) But you're right. Well, at least IMHO.

- Gábor (larta'H)
-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html