Blog: Memory Manager Development

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

Post Reply
Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Blog: Memory Manager Development

Post by Z98 » Tue Sep 09, 2014 8:59 pm


gamax92
Posts: 35
Joined: Sun May 05, 2013 5:40 pm

Re: Blog: Memory Manager Development

Post by gamax92 » Tue Sep 09, 2014 9:28 pm

Just to clarify something, in this quote "The ARM team began a rewrite" What is ARM referring to here?

ARM3 or the Processor Architecture?

If the latter, does any of this apply to x86?

Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Re: Blog: Memory Manager Development

Post by Z98 » Tue Sep 09, 2014 9:39 pm

ARM processor. And the memory manager was started for x86. They needed us to chuck the legacy MM on x86 before they could try to do anything MM related on ARM.

janl
Posts: 53
Joined: Thu Dec 16, 2010 10:26 pm

Re: Blog: Memory Manager Development

Post by janl » Wed Sep 10, 2014 6:32 pm

Yeah, he has his work cut out for him.
If Jérôme will be successful, he should be adequate rewarded (by money) considering resources from donations. Reactos will be more attractive.

dizt3mp3r
Posts: 1447
Joined: Mon Jun 14, 2010 5:54 pm

Re: Blog: Memory Manager Development

Post by dizt3mp3r » Thu Sep 11, 2014 4:02 am

Would it not be possible to look at the memory manager in an open source clone of VMS like FreeVMS and see how much of their memory manager they have implemented, with an eye to reusing some of their code? The good thing about FreeVMS is that they coded in C and not Bliss, http://en.wikipedia.org/wiki/BLISS

It might be an idea for cross-pollenisation. After all, the structures, and what they were trying to achieve would be pretty much the same (I assume) given that so much of what the Windows memory manager does was taken directly from VMS. I know that the FreeVMS project has been quiet for a while now but we don't know how much they achieved until someone actually takes a look. I know this idea is a bit left field but it might result in something useful.
Last edited by dizt3mp3r on Thu Sep 11, 2014 10:24 am, edited 1 time in total.

Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Re: Blog: Memory Manager Development

Post by Z98 » Thu Sep 11, 2014 5:49 am

If wikipedia isn't lying and FreeVMS uses L4 for its kernel, the answer is a firm no. It's also highly doubtful that the commercial VMS' memory manager looks anything like NT's. Re-usability of code that exists at the kernel level just does not happen between different operating systems unless the operating systems in question are of the same code base.

erkinalp
Posts: 837
Joined: Sat Dec 20, 2008 5:55 pm

Re: Blog: Memory Manager Development

Post by erkinalp » Thu Sep 11, 2014 9:43 am

This does not prevent having MM and processing schedulers shared among different OSes. This involves less porting than porting the whole kernel if they are properly abstracted away. You can see many many OSes with multi-level feedback queue in many different kernels, on Unix, on Windows, on VMS.
-uses Ubuntu+GNOME 3 GNU/Linux
-likes Free (as in freedom) and Open Source Detergents
-favors open source of Windows 10 under GPL2

dizt3mp3r
Posts: 1447
Joined: Mon Jun 14, 2010 5:54 pm

Re: Blog: Memory Manager Development

Post by dizt3mp3r » Thu Sep 11, 2014 10:19 am

I would have thought that the OpenVMS and Windows NT's implementation of the memory manager would be quite close logically, Mr. Cutler being involved in both. Certainly the structures that are exposed, pagedyn, npagedyn, sections &c, are carried over from VMS and a lot of NT seems familiar to any old VMS sys. admin.

However, it is all academic as you said, it is L4 based, I just found that on their site. Still, is it worth looking at their code to see what has been accomplished. One thing VMS was damn good at, was memory management. Any implementation of VMS would have had to focus on that as one their main goal, no GUI to worry about so they may have made significant progress in that direction and some might be re-usable... We'll only know by looking.

Anyway, it is just a suggestion. I see two good o/s, neither of which is complete and both would be nice to have...

Tonix
Posts: 89
Joined: Tue May 22, 2007 11:33 am

Re: Blog: Memory Manager Development

Post by Tonix » Thu Sep 11, 2014 11:01 am

Looking at the sources version 0.3 of freeVMS use a modified linux kernel, and versions 0.4 uses a L4 kernel...
every modern OS has a MM that support virtual memory, but how the memory is used by the Kernel is strictly
dependent by the type of OS.

Yes MM is a sort of driver, can be ported from another OS but it will be an hacked module in the kernel.

It has to be adapted to work with Reactos kernel.

Most of time adapt a piece of sw and mantein it is more a problem than a soultion.

For critical components a clean rewrite has to be preferred.


oldman
Posts: 1072
Joined: Sun Dec 20, 2009 1:23 pm

Re: Blog: Memory Manager Development

Post by oldman » Fri Sep 12, 2014 4:42 pm

by Webunny » 12 Sep 2014 13:45
Take my initiative of getting a voting on wallpapers to be included in ROS (trunk). It's been days if not weeks now. I've put it up on JIRA. I don't hear or see anything of/about it.
This is off topic, but in my opinion, the wallpaper will sit in Jira until the time comes when they (the Devs) want to include some wallpaper with an official release. Maybe you will see some or all of the wallpapers added into the community edition, but until that time comes, you will just have to be patient.
Please keep the Windows classic (9x/2000) look and feel.
The layman's guides to - debugging - bug reporting - compiling - with some complementary scripts.
They may help you with a problem, so do have a look at them.

Webunny
Posts: 1201
Joined: Sat Apr 28, 2012 1:30 pm

Re: Blog: Memory Manager Development

Post by Webunny » Fri Sep 12, 2014 5:34 pm

oldman wrote:
by Webunny » 12 Sep 2014 13:45
Take my initiative of getting a voting on wallpapers to be included in ROS (trunk). It's been days if not weeks now. I've put it up on JIRA. I don't hear or see anything of/about it.
This is off topic, but in my opinion, the wallpaper will sit in Jira until the time comes when they (the Devs) want to include some wallpaper with an official release. Maybe you will see some or all of the wallpapers added into the community edition, but until that time comes, you will just have to be patient.
Which is part of my point, really. I asked in front for official permisson to do it, so as to not waste my time. What you describe here, is a severe lack of communication and feedback for a community initiative. Also, one needs to communicate about it in front also from a technical stance, since the pictures there are not high res ones (due to technical limitations). For that, I need to know what wallpapers are included and which not.

You are factual wrong about the RCE, btw; this voting was *explicitly* meant for the trunk version, since Vic was going to organise something for the RCE.

PurpleGurl
Posts: 1777
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: Blog: Memory Manager Development

Post by PurpleGurl » Fri Sep 12, 2014 9:49 pm

Can we discuss the memory manager? I know it is an important part. What are the roadblocks in migrating the remaining functions of the old memory manager to ARM3? I know that the common cache functionality is a major roadblock, but what else?

Oh, and would this be a good place for a contract? The memory manager and the common cache seem to be a cause of a number of bugs and a holdup for other things like NTFS work. I tend to believe the contracts should first be awarded for major roadblocks to compatibility or function.

Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Re: Blog: Memory Manager Development

Post by Z98 » Sat Sep 13, 2014 5:32 pm

Roadblocks are pretty much the things stated in the blog post. Jerome has also made no indications he wants a dev contract, even when asked about it.

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Bing [Bot] and 2 guests