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

David Given
2004-05-26T14:17:47Z

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.

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.

* 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...

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

--
+- David Given --McQ-+ "P.S. If you do not receive this, of course it
| dg@cowlark.com | must have been miscarried; therefore I beg you to
| (dg@tao-group.com) | write and let me know." --- Sir Boyle Roche, in a
+- www.cowlark.com --+ letter
-
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