Blog: Memory Manager Development
Moderator: Moderator Team
Re: Blog: Memory Manager Development
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?
ARM3 or the Processor Architecture?
If the latter, does any of this apply to x86?
Re: Blog: Memory Manager Development
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.
Re: Blog: Memory Manager Development
If Jérôme will be successful, he should be adequate rewarded (by money) considering resources from donations. Reactos will be more attractive.Yeah, he has his work cut out for him.
Re: Blog: Memory Manager Development
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.
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.
Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.
Re: Blog: Memory Manager Development
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.
Re: Blog: Memory Manager Development
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
-likes Free (as in freedom) and Open Source Detergents
-favors open source of Windows 10 under GPL2
Re: Blog: Memory Manager Development
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...
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...
Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.
Re: Blog: Memory Manager Development
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.
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.
Re: Blog: Memory Manager Development
Understood.
Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.
Re: Blog: Memory Manager Development
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.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.
Please keep the Windows classic 9x/2000 look and feel.
The layman's guides - debugging - bug reporting - compiling - ISO remaster.
They may help you with a problem, so do have a look at them.
The layman's guides - debugging - bug reporting - compiling - ISO remaster.
They may help you with a problem, so do have a look at them.
Re: Blog: Memory Manager Development
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.oldman wrote: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.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.
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.
-
- Posts: 1790
- Joined: Fri Aug 07, 2009 5:11 am
- Location: USA
Re: Blog: Memory Manager Development
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.
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.
Re: Blog: Memory Manager Development
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.
Who is online
Users browsing this forum: Google [Bot] and 33 guests