Login
Username:

Password:

Remember me



Lost Password?

Register now!
Main Menu
Who's Online
1 user(s) are online (1 user(s) are browsing Forum)

Members: 0
Guests: 1

more...

Browsing this Thread:   1 Anonymous Users



« 1 ... 3 4 5 (6) 7 »


Re: Aros Memory Protection

Joined:
2009/12/25 19:55
Group:
Member
Posts: 93
Offline
yea whatever, you all, aros dev and contributors, will end up doing it all sooner or later anyway.
or else aros will be put to sleep someday, for not having enough active community members if this ain't get done.
multi-core cpu support, memory protection, unicode ....
you'll do it all and you're still wasting time
you know it already that os3.x api compatibility won't take you far on the long run, it's already terribly outdated.
i'll look at you try to resit and bend before breaking (compatibility of course ;)

Posted on: 2011/5/14 10:51
Transfer the post to other applications Transfer


Re: Aros Memory Protection

Joined:
2008/2/4 8:39
Group:
Member
Posts: 823
Offline
@freeaks
Quote:
that's why aros ain't worth my time.

Fine, go play elsewhere then.

@all
Back to the topic please.

@Fats
Quote:

Fats wrote:
Quote:

HenryCase wrote:

With all due respect, how in Jah's name do you expect a pure single address space to work with implementing MP?


Maybe like how some of these OSes does it? Did you actually try to look at some of them ?
I am not inventing something out of hot air.


Thanks for the link, but to be absolutely clear on what I meant, I meant how is a single address space going to work for us, not for other OS where it's been part of the design from the start. I do not see how we can retrofit MP to AROS without either;
1. Using virtual memory spaces.
2. Altering application source code.

I'm interested in option #1, option #2 is not something I wish to consider as I believe it would have a negative impact on the project. There might be a workaround for #2 through changing how compilers function, but that's maybe something to discuss another time.

I looked at the operating systems in that Single Address Space Operating Systems list, and here's what I found out about the ones with active links:

------------------------------------------------------
Mungi - "How does Mungi prevent users from bypassing the capability-based protection system? When are capabilities validated?
All objects are in virtual memory (VM)."
http://www.ertos.nicta.com.au/research/old/mungi//faq.pml

Iguana - "While it borrows many ideas from the Mungi operating system"

"Iguana supports the separation of protection and translation, by encouraging a non-overlapping address-space layout. This means that Iguana-based systems can be readily deployed on processors without virtual memory, and can also obtain the best possible performance on the ARM7 and ARM9 cores widely used in embedded systems."
http://www.ertos.nicta.com.au/softwar ... oject/latest/overview.pml

Nemesis - "The guiding principle in the design of Nemesis was to structure the operating system in such a way that the majority of code could execute in the application process itself. Nemesis therefore has an extremely small lightweight kernel, and performs most operating system functions in shared libraries which execute in the user's process."
http://www.cl.cam.ac.uk/research/srg/netos/old-projects/nemesis/

Opal - "Protection in Opal is independent of the single address space; each Opal thread executes within a protection domain that defines which virtual pages it has the right to access."
http://www.cs.washington.edu/homes/levy/opal/opal.html

Sombrero - "In the past few years the advances in silicon fabrication technology and VLSI design techniques have led to the manufacture of microprocessors with 64-bit internal data paths, registers and arithmetic units. These modern processors can support a 64-bit virtual address space. Simple arithmetic shows that one could create a new 4 gigabyte object, the size of a full virtual address space on a conventional 32-bit processor, once a second for 136 years and not exhaust the available namespace. This large address space is sufficient to store all of the data associated with most applications for the lifetime of the application."
http://sombrero.engineering.asu.edu/sombrero.htm

Torsion - "An Address_map is a generalized two-level hierarchical map of virtual addresses to some corresponding values."
http://torsion.org/docs/api/html/classAddress__map.html

Baremetal OS - "Monotasking
The philosophy behind BareMetal OS is to run one application at a time."
http://www.returninfinity.com/docs/Ba ... S%20-%20Architecture.html

Br1X - "Safe-language -- BRiX uses a special language that guarantees fine-grained safety instead of relying on hardware that only isolates programs from each other and does nothing to protect a user's data from programs running as that user."
http://brix-os.sourceforge.net/?p0=info

Scout - "Scout uses a non-preemptive scheduler because it meets our needs and is easy to use. In the future, Scout will allow for uncooperative ``threads,'' but since it is not a good idea to share any resource with uncooperative threads in an uncontrolled manner, those threads will not share memory either. That is, uncooperative threads will be isolated from each other in some manner (e.g., through separate address spaces, fault isolation, or a safe language)."
http://www.cs.arizona.edu/projects/scout/Papers/osdi96/doc004.html

Singularity (operating system) - "applications are all written in managed code"
http://en.wikipedia.org/wiki/Singularity_(operating_system)
------------------------------------------------------

Let's summarise what this information shows:
1. You can get MP in a single address space OS if you use managed code (Br1X, Singularity).
2. Monotasking operating systems do not need the overhead of virtual memory or MP (Baremetal OS).
3. You can get around MP issues by giving each application a copy of the needed system code (Nemesis).

None of the three above can be sensibly applied to AROS. The rest of the operating systems listed (Mungi, Iguana, Opal, Sombrero, Torsion, Scout) use virtual memory spaces in some way, admittedly the memory management structure of Iguana was least clear, but seeing as it's closely linked to Mungi I don't feel compelled to look into it further.

To me the most interesting find was that of Sombrero. Would you be more open to virtualised memory spaces if you didn't need to worry about virtual memory overheads?

Quote:
I don't think the OS can magically know if certain memory is to be shared between these two tasks and not by another task. If you want such fine grained MP you will need to tell it to the OS.


Yes, the OS will know about the MP, that's part of what I'm proposing. I'm aiming to put together an MP plan for AROS that doesn't require changing applications and doesn't require changing the expected functionality of the API these applications use, but changes to the OS itself are fair game IMO.

Quote:
Alternative, and I think what you guys propose, is the Unix/Windows way where each process only talks to the OS and communication between processes is done by copying memory and not being able to pass pointers in between tasks.
IMO this does not fit in an amiga-like OS.


No, again you misunderstand me, you can pass pointers in between tasks with my solution too, you just need to check data if it crosses boundaries. I can explain how if you're interested, but this post is too long as it is, so I'll hold off for another post.

Validating data is an important part of MP, I don't understand how you'd have MP in AROS without it. If applications aren't aware of MP, you have to control them so that they can act up without damaging the whole system. Think about it like controlling crime. You can't reprogram criminals to so that they never break the law (i.e. unlikely to catch all errors by changing application source code) but you can catch criminals and lock them away (application crashes rather than whole OS). Trying to do MP in AROS without data validation is like trying to catch criminals you can't see, you're making it unnecessarily hard to achieve.

Look forward to hearing your thoughts on this post.

EDIT: Oh and before I forget, found this interesting OS concept whilst I was researching:
http://en.wikipedia.org/wiki/Exokernel
http://pdos.csail.mit.edu/exo/
Very interesting structure, makes the OS as flexible as possible, tunable for optimum application performance. The performance graph on the MIT Exokernel page gives a glimpse of the power of the Exokernel approach.

Posted on: 2011/5/14 11:27

Edited by HenryCase on 2011/5/14 12:04:28
Edited by HenryCase on 2011/5/14 12:22:32
Edited by HenryCase on 2011/5/14 12:25:47
Edited by HenryCase on 2011/5/14 12:29:16
Edited by HenryCase on 2011/5/14 12:34:33
Transfer the post to other applications Transfer


Re: Aros Memory Protection

Joined:
2009/12/25 19:55
Group:
Member
Posts: 93
Offline
@henrycase
what ? i'm an ex-amiga user, i was on topic, speaking of advances of aros and memory protection.
i said it should be done, and probably will .. this is ontopic normal talk on a forum ..

the problem is big, and it annoy ppl when the subject get brought on the table again, but hidding it under the carpet doesn't help either.
amiga-like OSes still have to develop a solution for this problem.


Posted on: 2011/5/14 11:58
Transfer the post to other applications Transfer


Re: Aros Memory Protection

Joined:
2008/2/4 8:39
Group:
Member
Posts: 823
Offline
@freeeaks
Let me ask you this, (in this thread) do you think you're conducting yourself in a manner which is helpful?

If you'd understood what was written in this thread you'd see we're looking at ways to bring MP to AROS without giving up on AROS' goals. MP does seem possible at the moment, we're just ironing out the approach that best fits AROS.

Your issue doesn't seem to be with MP, but rather the goals of AROS. You believe AROS' goals hold it back, we do not. If you do not think the goals of AROS are worthwhile then you are wasting your time here. If you feel strongly enough that the direction is incorrect, then start your own project. To help you get started you can choose to fork AROS code, if you wish.

Hope you can either provide a positive contribution to this thread or find a better use of your time.

Thanks.

Posted on: 2011/5/14 12:15
Transfer the post to other applications Transfer


Re: Aros Memory Protection

Joined:
2007/10/23 8:47
From Los Angeles,CA
Group:
Member
Posts: 805
Offline
@freeeaks
the way you talk remind me the one of an italian user [D] on Appuntidigitali.it; is that you?

Saimon69

Posted on: 2011/5/14 12:49
_________________
Kitteh Fav OS since 1995 =^x^=
---
Scarabocchi Binari - blog
Binary Doodles - english blog
Twitter
Transfer the post to other applications Transfer


Re: Aros Memory Protection

Joined:
2009/3/15 4:41
Group:
Member
Posts: 612
Offline
I don't know if there must be a fork to an incompatible AROS-NG.
Maybe such an AROS-NG would be compatible enough for most AROS/AOS3.x compatible sources to be compiled with none or a minimum of changes.
I don't know if such an AROS-NG should be a new AROS kernal or if it would be better to build a wrapper for an existing system like Linux or BSD.

All I know I want to have some memory protection to increase system stability and I want to have it as fast as possible. Even if there might be a better way for a future AROS system, an simplified system could be done fast and it would not stop a future MP system.

I just wanted it configurable, because I could imagine all the postings about programs that stopped working after this system is inserted into the system, maybe even some main system functionalities will lead to memory access violations.

cu GN

Posted on: 2011/5/14 13:56
Transfer the post to other applications Transfer


Re: Aros Memory Protection

Joined:
2008/2/4 8:39
Group:
Member
Posts: 823
Offline
@GreenNight
Quote:
Even if there might be a better way for a future AROS system, an simplified system could be done fast and it would not stop a future MP system.


As I told you before, this partial MP is already being worked on, so what are you complaining for? Just because it's not here now? Please be patient.

@all
Enough already with the thread derailing. If you want to complain about something make a new thread, this thread has the chance to further our understanding of MP solutions for AROS. If you feel something is above your level then ask about it and we can discuss it, but please try to keep your posts focused on the topic at hand, we will all benefit if we do.

Okay, so a question, what are the pros and cons of using virtual memory spaces?

Posted on: 2011/5/14 14:19
Transfer the post to other applications Transfer


Re: Aros Memory Protection

Joined:
2004/4/12 13:07
Group:
Member
Posts: 531
Offline
Quote:

HenryCase wrote:

No, again you misunderstand me, you can pass pointers in between tasks with my solution too, you just need to check data if it crosses boundaries. I can explain how if you're interested, but this post is too long as it is, so I'll hold off for another post.


Please enlighten me.
I don't see how you can ever get this to work without changing source code of programs. The problem I see is that the OS does not have any way to know when a boundary is crossed.
Again the same comments you did not fully address:

- Simply enforcing MEMF_PRIVATE/MEMF_PUBLIC rule for allocated memory would crash a lot of current programs.
- Do you plan to put MP on memory allocated with MEMF_PUBLIC ?
- Does CreateNewProc create a new boundary in your terminology ? AddTask ? My claim is that it sometimes should and sometimes not and the OS can't know unless source code of the program is changed to tell it to the OS.
- How would you handle files that are opened in one task and read/written to in another task. I think several programs are doing that ? This is just an example and I think Amiga API is full of such things.

Another worry is that the continuous checking you want to implement will degrade the performance of the message passing. What I mean is that the MMU should do the checking, not some code somewhere. Interrupts should only happen when memory is wrongly accessed; not to ask to the OS to check if a certain access is OK.

greets,
Staf.

Posted on: 2011/5/14 15:32
Transfer the post to other applications Transfer


Re: Aros Memory Protection

Joined:
2004/4/12 13:07
Group:
Member
Posts: 531
Offline
Quote:

HenryCase wrote:

EDIT: Oh and before I forget, found this interesting OS concept whilst I was researching:
http://en.wikipedia.org/wiki/Exokernel
http://pdos.csail.mit.edu/exo/
Very interesting structure, makes the OS as flexible as possible, tunable for optimum application performance. The performance graph on the MIT Exokernel page gives a glimpse of the power of the Exokernel approach.


I think Microkernels seem to represent more the architecture of AROS. The exokernels seem to do away with the message passing, e.g. turning AROS into an exokernel would need to remove the message passing functions from exec.
From the other side you can argue that kernel.resource people are evolving to is actually an exokernel and exec.library is just a library on top of it.
But what is in a name ? To me what counts is that the message passing API is a fundamental building block of an amiga-like operating system.

greets,
Staf.

Posted on: 2011/5/15 2:30
Transfer the post to other applications Transfer


Re: Aros Memory Protection

Joined:
2004/4/12 13:07
Group:
Member
Posts: 531
Offline
Quote:

HenryCase wrote:

Mungi - "How does Mungi prevent users from bypassing the capability-based protection system? When are capabilities validated?
All objects are in virtual memory (VM)."
http://www.ertos.nicta.com.au/research/old/mungi//faq.pml

Iguana - "While it borrows many ideas from the Mungi operating system"


You seem to confuse virtual memory with single/multiple address spaces.
Like said before in these OSes all programs see the same address space but not all programs have the same access to the same memory regions.

Quote:

...

Let's summarise what this information shows:
1. You can get MP in a single address space OS if you use managed code (Br1X, Singularity).
2. Monotasking operating systems do not need the overhead of virtual memory or MP (Baremetal OS).
3. You can get around MP issues by giving each application a copy of the needed system code (Nemesis).


You left out the important one which I think can be a guide for an AROS implementation:
0. In all programs the same pointer points to the same data but access restrictions are different between different programs.

greets,
Staf.

Posted on: 2011/5/15 2:47
Transfer the post to other applications Transfer



« 1 ... 3 4 5 (6) 7 »



You can view topic.
You cannot start a new topic.
You cannot reply to posts.
You cannot edit your posts.
You cannot delete your posts.
You cannot add new polls.
You cannot vote in polls.
You cannot attach files to posts.
You cannot post without approval.

[Advanced Search]


Search
Top Posters
1 paolone
paolone
4358
2 magorium
magorium
4095
3 phoenixkonsole
phoenixkonsole
3892
4 nikolaos
nikolaos
3693
5 deadwood
deadwood
2923
6 ncafferkey
ncafferkey
2644
7 mazze
mazze
2214
8 clusteruk
clusteruk
2109
9 Kalamatee
Kalamatee
2024
10 damocles
damocles
1789
© 2004-2017 AROS Exec