»

[SamuraiCrow]

Regarding memory protection:

1. Can it be done?
2. Can it be done elegantly?
3. Should it be done?

1. It can only be done part way and it requires an MMU.
2. No, managed code is much more elegant even if it is sometimes a bit slow.
3. No. If we are going to support the Natami and MiniMig as a starting place, we're going to have to realize that the fact that the 68070 on the production Natami and 68000 on the MiniMig will not have an MMU is going to prevent a memory-protected AROS from running at all!

There are so many things that should be done first:

1. Standard Template Library for C++ code. This can be implemented using STLPort.
2. Expand the runtime library to do STL functions in a memory-efficient manner. This can be implemented through template specialization.
3. Minimal bytecode as a distribution medium for code across all of the supported hardware platforms. (Possibly even portable to all of the OSs that support AmigaOS 3.1 APIs.) Tough one but but I favor LLVM to implement this.
4. Compiler to generate code in that bytecode. LLVM-GCC does this but is difficult to build. The upcoming Clang project on the Mac might someday be a better choice though.
5. Entry level programming languages. Another tough one but I'm already working on this one. Hollywood also works for this one.

[HenryCase]

SamuraiCrow wrote:
Regarding memory protection:

1. It can only be done part way and it requires an MMU.
2. No, managed code is much more elegant even if it is sometimes a bit slow.
3. No. If we are going to support the Natami and MiniMig as a starting place, we're going to have to realize that the fact that the 68070 on the production Natami and 68000 on the MiniMig will not have an MMU is going to prevent a memory-protected AROS from running at all!

SamuraiCrow thanks for your reply, but you're jumping ahead in the discussions here. As I said before I see no point discussing questions 2 and 3 until we come to an agreement on the answer to question 1. The only way you're going to convince me that MP can only be done partially is to find flaws in the MP solution I outlined earlier in this thread. Please do so. Thanks in advance.

[itix]

@HenryCase

One problem in memory protection is that applications and the operating system are sharing system structures. For example when you call OpenWindow() the system returns struct Window which is globally shared. If your application trashes this structure it may lead to crash of operating system.

The design of Amiga is unfortunately flawed for memory protection. One could say that on Amiga there is no user space and kernel space -- there is only kernel space where all applications are running.

[paolone]

Oh no! Another "how should other people work" topic about AROS.

And another fork/split proposal. It seems the Amiga community can't live without splitting things in thousands pieces.

Well, for people that aren't aware of it, AROS has its own mission and definition, which is being "a lightweight, efficient and flexible desktop operating system, designed to help you make the most of your computer. It's an independent, portable and free project, aiming at being compatible with AmigaOS 3.1 at the API level (like Wine, unlike UAE), while improving on it in many areas".

Isn't it enough? Well, there are the ending lines too, "The source code is available under an open source license, which allows anyone to freely improve upon it" which formally and actually allow anyone willing to do his/her "better AROS" to take the code, modify it and reach the goal he/she likes.

So, having clear in mind that all in all AROS is a *hobbystic* project, the community can do different things with it:

1. just whining and claiming their opinion would be the best way to improve AROS

2. contribute with code to reach the common goal stated above.

3. take the existing code and improve upon it the way they like, just to become the new ruler of the world.

The direction is already here for the people that want to see it. The others may disagree, but please don't claim AROS is pointless or directionless anymore, as it is completely untrue.

[HenryCase]

itix wrote:
@HenryCase
One problem in memory protection is that applications and the operating system are sharing system structures. For example when you call OpenWindow() the system returns struct Window which is globally shared. If your application trashes this structure it may lead to crash of operating system.

Thanks for your reply itix. I looked into the OpenWindow() API call and I can't see anything that would prevent changing it from a global variable to a more local one.

itix wrote:
The design of Amiga is unfortunately flawed for memory protection. One could say that on Amiga there is no user space and kernel space -- there is only kernel space where all applications are running.

This is the case now, but we're looking at ways to create a user space-kernel space separation whilst keeping OS3.1 API compatibility. This is not your daddy's exec if you catch my drift. If it is possible to implement a new kernel with MP that supports the OS3.1 API calls then we can have MP in an Amiga based OS.

So a good question is this: are there any global variables that cannot be contained more locally?

[HenryCase]

paolone wrote:
The direction is already here for the people that want to see it. The others may disagree, but please don't claim AROS is pointless or directionless anymore, as it is completely untrue.

Paolone, I don't know if I was meant to be one of the targets of your 'all talk no action' rant or not, but I wanted to tell you that I really believe VmwAROS is a great asset to the AROS (and Amiga) community, and is helping to bring some structure back to AROS application development. Thank you for your continued work on it.

[itix]

@HenryCase

Thanks for your reply itix. I looked into the OpenWindow() API call and I can't see anything that would prevent changing it from a global variable to a more local one.

Local in which way? Intuition reads and writes to this structure and application reads and writes to this structure. There is no way you could make it "local" and retain API compatibility.

If it is possible to implement a new kernel with MP that supports the OS3.1 API calls then we can have MP in an Amiga based OS.

If it was possible AROS would have implemented it already.

[bloodline]

Henry...

There is only one small conceptual point that you are missing. I have been racking my brains to try and find a good metaphor for the problem... bur I can't really find one.

I want to address your conceptual error as you raised it before... That is this strange idea of your that a program requests data from memory. It doesn't.

What we have is a big flat area of memory, and a CPU.
The CPU does not know or care where it is reading and writing, it simply follows what it is told to do by a computer program. The CPU in AmigaOS has no information regarding the status of the code at all. While AmigaOS offers contexts (where each exec task has it's own set of certain data structures etc), these contexts are all part of the same address space.

In the AmigaOS design, the designers decided that they wanted the system to be fast and use as little memory as possible. Thus AmigaOS was designed with the idea that any data structure that could be shared, would be shared... No provision was made in the design of Amiga to control the access to system wide data structures... this was a design decision, and it can't be retro fitted without totally redesigning the system, and it would no longer be AmigaOS compatible.

You are thinking high level, not machine level... Your ideas are actually an area of research called "managed code", the most famous is MicroSoft's Singularity project. There programs access memory via defined system functions thus memory access can be controlled without the need for an MMU.

But AmigaOS is not a managed code system, it was designed as an operating system to be programmed at a machine code level... in fact I can write a program in ASM that would work on AmigaOS in a matter of minutes... I certainly couldn't even begin to think about doing that on a real operating like a UNIX or Windows... where I would have to stick with C.

[HenryCase]

itix wrote:
Local in which way? Intuition reads and writes to this structure and application reads and writes to this structure. There is no way you could make it "local" and retain API compatibility.

Can you talk me through the way OpenWindow() is used in OS 3.1 so that I can look at creating this separation based on how it actually works and not my basic interpretation of Amiga API guides from the Internet.

itix wrote:

If it was possible AROS would have implemented it already.

I don't believe that MP was/is inevitable. There were more important tasks to complete when the AROS kernel was designed and created, like just getting it to work.

[bloodline]

HenryCase wrote:

Thanks for your reply itix. I looked into the OpenWindow() API call and I can't see anything that would prevent changing it from a global variable to a more local one.

But the data structures are shared... Every program ever written for AmigaOS and the System itself expect to have access to these data structures... what do you want to do? Give each one it's own local copy of intuition? How the hell could that work? The way intuition was designed doesn't allow for that!

This is the case now, but we're looking at ways to create a user space-kernel space separation whilst keeping OS3.1 API compatibility.

There is no separation in the design of the API... the actual concept of the OS is everything running in Kernel Space... This isn't a push a button and the Kernel is in a separate space problem... there is no separation in the API design!

This is not your daddy's exec if you catch my drift.

No, you really need to spell this out because it is currently a hidden component in your theory and possibly one that is causing your confusion.

If it is possible to implement a new kernel with MP that supports the OS3.1 API calls then we can have MP in an Amiga based OS.

But those very same API calls return pointers to shared data structures... how do you get around that?

So a good question is this: are there any global variables that cannot be contained more locally?

That's an irrelevant question, you are thinking as if the CPU is running high level code, it is not.

[dammy]

Money, lots and lots of money spread over many years. If you can hire devs and guide them with vision of a great future, you can move AROS forward.

Dammy

[SamuraiCrow]

@HenryCase

Any time you see a structure being passed into a system function with an &structurename in C code, it is passing a pointer to an internal stucture in the application's memory to the operating system. More importantly, if the operating system allocated the memory and passed back the pointer, the operating system would be the owner of that memory and would have to "change ownership" to the application and "change ownership" back to the operating system every time a pointer was passed back to it. That would be a glacially slow operation.

I think the answer to the issues that are often associated with memory protection are generally better addressed by using "safe" programming languages like Oberon and some versions of Basic that either don't directly support pointers in general, or have tight limitations on the use of arrays and other data structures to monitor them for overruns and NULL pointer values internally.

[Hans_]

@SamuraiCrow

SamuraiCrow wrote:
@HenryCase

Any time you see a structure being passed into a system function with an &structurename in C code, it is passing a pointer to an internal stucture in the application's memory to the operating system. More importantly, if the operating system allocated the memory and passed back the pointer, the operating system would be the owner of that memory and would have to "change ownership" to the application and "change ownership" back to the operating system every time a pointer was passed back to it. That would be a glacially slow operation.

Anything running in supervisor mode should have full access to all memory in the system. Thus, the OS kernel wouldn't have to change ownership back and forth. For non-kernel OS modules that run in user mode, they could run directly in the application's task/process; this means that there still wouldn't be any ownership change.

I think the answer to the issues that are often associated with memory protection are generally better addressed by using "safe" programming languages like Oberon and some versions of Basic that either don't directly support pointers in general, or have tight limitations on the use of arrays and other data structures to monitor them for overruns and NULL pointer values internally.

The problem with that is that it requires all software to play by the rules. Malicious code does not. Memory protection helps prevent malicious code from doing harm by restricting access to resources.

Hans

[HenryCase]

@bloodline
Thanks for your response.

bloodline wrote:
What we have is a big flat area of memory, and a CPU.
The CPU does not know or care where it is reading and writing, it simply follows what it is told to do by a computer program. The CPU in AmigaOS has no information regarding the status of the code at all. While AmigaOS offers contexts (where each exec task has it's own set of certain data structures etc), these contexts are all part of the same address space.

I agree, the CPU doesn't have to care where it is reading or writing, it just has to follows what it is told to do by a computer program, namely the new AROS memory manager I am proposing. AROS is software too. I'm taking control over memory from the applications and giving it to the OS. If a program uses an API call like AllocMem() then AROS knows about it, right?

bloodline wrote:
In the AmigaOS design, the designers decided that they wanted the system to be fast and use as little memory as possible. Thus AmigaOS was designed with the idea that any data structure that could be shared, would be shared... No provision was made in the design of Amiga to control the access to system wide data structures... this was a design decision, and it can't be retro fitted without totally redesigning the system, and it would no longer be AmigaOS compatible.

Clearly I'm not aiming to clone every design decision made by the AmigaOS designers. I'm trying to focus on how we keeping OS 3.1 API compatibility in a MP system, we can discuss if the resultant OS is Amiga-like later.

bloodline wrote:
You are thinking high level, not machine level... Your ideas are actually an area of research called "managed code", the most famous is MicroSoft's Singularity project. There programs access memory via defined system functions thus memory access can be controlled without the need for an MMU.

Interesting. Can you give me an overview of how Microsoft's Singularity achieves this feat?

bloodline wrote:
But AmigaOS is not a managed code system, it was designed as an operating system to be programmed at a machine code level... in fact I can write a program in ASM that would work on AmigaOS in a matter of minutes... I certainly couldn't even begin to think about doing that on a real operating like a UNIX or Windows... where I would have to stick with C.

AmigaOS may not have been a managed code system historically, but we're not looking at what it was but rather what we can make it without breaking compatibility. You'd still be able to code in ASM with my MP system. The programs making AmigaOS API calls see the 'virtual' memory layout, but the users of the OS can see the 'virtual' memory layout and the 'real' memory layout. I hope you can see that gives us options to allow ASM code to run alongside other code.

One option is to add a new API call(s) especially for ASM code. When the ASM program is executed it first makes an API call that says something like 'I will need memory from XXXX to XXXX to run'. If this memory is free then it is assigned to the ASM program. If it is not free you can either:

1. Close the programs using that memory.
2. Move the programs using the memory to another memory space (the programs are paused during this move, but can carry on afterwards as normal due to the 'virtual' memory addresses not moving.
3. A copy of the ASM program is made, and this copy is amended with available memory address locations before being run (the application doing this works like a find and replace function in a word processor).

However, ASM by its nature does not allow MP(AFAIK), unless you sandbox it, so yes you could crash AmigaOS with a badly coded ASM app, but the same is true of any operating system. If you code ASM apps so that they stay out of the way of the area where the OS is running from you should be okay.

[HenryCase]

@bloodline
I'll reply to your last post shortly, outlining my ideas for the new exec will take a little time.

@Hans

Hans_ wrote:
Anything running in supervisor mode should have full access to all memory in the system. Thus, the OS kernel wouldn't have to change ownership back and forth. For non-kernel OS modules that run in user mode, they could run directly in the application's task/process; this means that there still wouldn't be any ownership change.

Correct. The memory in use would be jointly owned by the kernel and the applications permitted to run in that space. This allocation only changes when you close an application or give a new application rights to use that space.