Quote:

My personal thoughts are to run an UnMP-AROS hosted on an MP-AROS... MP AROS would run MP safe apps and UnMP-AROS would run MP Unable apps...

I'm sure there are many problems that Adam and Fabio will point out with that idea though.

Quote:


Cool! Just to put my 2 cents worth on the memory usage. Memory is getting cheaper and cheaper. I would rather use more memory and have a more stable system. As far as I can tell Amiga/Aros programs use much less memory than Windows programs. So, does anyone have any idea how much memory overhead this would imply? Could using this type of MP be an option so that if you had enough memory you could use it and if not you could turn it off?

I was going to ask the devs is we could protect MEMF_CHIP and MEMF_FAST with the MMU.

Only MEMF_PUBLIC would be unprotected.

And take it from there... since most programers wouldn't mind looking at their old source code before an AROS compile, it might work out ok.

Wow! Does this thread take you back or what? I remember discussions with Dave Haynie on this and multi-processor support.

The big problem with memory protection was that nobody followed the rules. Even I didn't. Did you ever embed a port or an IO in your program? You broke the rules. You were supposed to allocate memory with the MEMF_PUBLIC flag for things like that. This would allow the eventual use of memory protection and virtual memory. Programmers just ignored all that because all memory was public at the time. There wasn't any incentive to follow the rules as it meant extra work.

AROS was designed to be source compatible with 3.1 programs. This means it inherited all the same problems. They aren't insurmountable, but they mean having to make work-arounds in the system that shouldn't have been needed.

Sometimes, it was lack of foresight by OS team. For example, the Amiga OS had macros for DISABLE/ENABLE and FORBID/PERMIT. These macros did the same thing as the exec functions, so they were a speedup for programmers. The problem is that they broke the ability to easily make the OS multi-processor compatible. For multi-processor support, everyone needs to use the exec functions, not the macros. With AROS, this just means recompiling with the functions. On the Amiga, it meant you would have to use the MMU to protect the exec library structure. When the macros directly alter TD_NestCnt, you would need to trap the access with the MMU so you could then do the appropriate function. While this would work, you can see that it's not as fast compared to if the program had called the function instead.

So never use macros for memory or cpu functions. These can and will change to support advanced features. Try to follow the rules, even if you know they can be bent.

Quote:

Yup you've got it. Sandboxing is expensive on Memory. And there will be two types of program... thoses that Do MP... and those that don't :-/

In the long run MP is needed... but implementing it wil lrequire a LOT of reworking.

Though I'm pretty sure this can be resolved...

Thanks for the info! OK, so here we talk about the sanbox, each program getting it very own little Aros and some Apps having a "...nice MP enviroment." I am not sure what the difference in your explination are. I thought that the sandbox was the MP. It seems that the sandbox might require more memory per program to run, that is just fine with me. I just want Aros to be as stable as it can be. Are we talking about 2 different "types" of apps. Those coded with no MP in mind and those coded using the proposed Aros MP?

P.S. Not trying to be a nag here. Just trying to get a clear understnding. Just as a side note. I really want to say "Thanks" to the Aros people in general. I get all kinds of crazy questions answered from them. They even keep at it till I actually get it.

Quote:

The idea that each App gets its own little AROS. Very similar to our UAE integration idea.

This is the only way to get Amiga API apps to run, since they have always assumed no memory protection.

If we were to add memory protection to AROS it would become incompatible with existing Amiga Software (but some would say that the x86 makes AROS incompatible anyway... so we may as well do it... but stuff like Intuition would have to be totally reworked in an MP environment).

What I want to see now is just how far one can abstract the API and allow Some Apps to be sandboxed and some to run in a nice MP environment.

Ok, in Captain Dummy speak please. What is the "Sandbox" approach?

by Ash-Fox on 2004/4/8 4:05:44

Quote:

Other then a sandbox approach, I have yet to hear how it could be possible with the current AROS. Which is a great pity since I would love to see MP (as well as multi-user and SMP) for AROS. Guess there is always the sandbox approach but that will require an AROS emulator?

Dammy

Quote:

Actually they haven't managed it

All they have done is protected the Free mem, if you accidentally write to an allocated memory area, the OS won't care and the poor app that got written over will die.

However I'm now pouring over the RKMs... I will talk to Fabio and Adam about any thing that I can see. Remember this probalem has defieted some of the gretest minds of the Amiga world... it's a hard problem to solve. The API is broken in that respect... (Though it seems clear that something was thought about Memory Protection)