V2 Operating System Memory Management Proposal III by Dave Poirier About this proposal ------------------- This document supersede the document entitled "V2 OS Memory Management Proposal II" I distributed on May 19th, 2000. It's an answer to the various e-mails I received and a guide to a memory implementation for V2_OS. This is a draft document, it will stay on the internet, available for users and developers' review for a period of 2 weeks. After that point, if no major change has been made, a document with the necessary modifications will be published as official and the memory implementation process will start. In case of a consensus toward a major modification of the current draft, another would be written for further review, and the process repeated. This two weeks period is your opportunity to make your suggestions or comments and correct any error present. Please feel free to review and critique this document as much as you like, it is most certainly appreciated. A copy of the most recent version of this document will be available at the following address for an undetermined period of time: http://ekspace.isuisse.com/ekspace/proposal.txt Older copies should be available at the same site, replacing the two last letters by the version number. So something like: propos_2.txt will point to the superseded version 2 of the proposal. I Hope this will help some of you better understand the inner working of the V2 operating system and maybe make the V2 OS community work even more together toward an even more defined goal. written by Dave Poirier, on Friday May 18th, 2000 email : futur@mad.scientist.com website: http://ekspace.isuisse.com/ Table of Content ---------------- 1. A few words on V2_OS 2. What was wrong with proposal 2 3. A Simple and Efficient memory management 3.1 Allocate 3.2 De-Allocate 4. Changes required in the V2_OS kernel 5. Note on the incoming replacement of interrupt 20h 1. A few words on V2_OS ------------------------ There's been a general tendency in the last couple of weeks, in the V2 OS community, to forget where the V2 Operating System was originally heading. In fact, many of the developpers began their own modified release of the os or in some cases, started parallel or concurrent os. While its true that there isn't only one way to do things, I find that it is important to keep ourselves focused on a purpose, a goal, and try to meet this goal with the best possible terms, together, and so become a society in itself. V2_OS was originally developped by Joost at the V2_Lab in the Netherlands. It was aimed at multimedia and entertainment applications, offering a lite, small, fast and fully optimized operating system. Its file system was designed to provide maximum speed to this type of applications and the whole architecture was designed toward them. When I develop for the V2 Operating System, I try to follow these goals, by optimizing and even sometime trading a functionality for a speed increase. Games and multimedia applications are highly optimized and tend to prefer to use their own graphic and memory management routine. But while these types of applications requires almost only to be loaded in memory and given total control, some other type of application need a little bit more support from the operating system. Since V2_OS is aimed mostly at higly optimized applications and V2_OS users will also used other types of application, it is important to be able to support both types, highly optimized and more general, applications. This draft document was design toward this goal, toward speed. 2. What was wrong with proposal 2 --------------------------------- One of the kernel developper remembered me of one thing: simplicity. While I was designing the previous proposal (version 2), I forgot to make it simple. One thing that were mentioned by VP was that there's no protection mechanism at all in the V2 Operating System, so why should I include an authorisation code (see proposal version 2). He also remembered me of another thing, we will soon make drastic changes in the architecture of V2_OS. One of them will be to remove the int 20h service dispatcher and replace it with a call table (pointers to services so we can call directly instead of using an interrupt, see LTH's specs). So I find myself on this saturday morning rewriting, in the hope of making it better, the memory management specifications. I hope this draft will better fit the objectives of the V2_OS Community. Like always, comment it 3. A Simple and Efficient memory management ------------------------------------------- Simplicity and efficiency are the two most difficults objectives to achieve. While someone may find one way really simple, the same way for somebody else may look terrible and extermely complicated, and it goes like that also for efficiency. The memory manager would work with the 4GB of memory, like it currently is working in V2_OS. It will keep a pointer to the allocated memory, and simply update this pointer when it allocate and de-allocate memory. A few servicses must be implemented. They are: - Allocate memory - De-Allocate memory 3.1 Allocate memory ------------------- sub-service: 1 Basically the same service as his currently implemented. It would allocate a memory segment at the end of the allocated space, create a descriptor inside the gdt and return both the address to the created segment and the selector. parameters: DL type of segment 0 = data 1 = code DH default operand size (data segment only) 0 = 16 bits 1 = 32 bits EBX segment size in bytes returned values: CX selector of the newly created segment EDI linear address to the segment error code: none always successfull destroyed registers: CX, EDI 3.2 De-Allocate memory ---------------------- sub-service: 2 Replace the service called 'Delete selector'. The new service would de-allocate the specified block, freeing it, and update the 'top of allocated memory' pointer. parameters: BX segment selector returned values: AL error code register destroyed: AL error codes: 0 completed successfully 27 invalid segment selector 4. Changes required in the V2_OS kernel --------------------------------------- Only SR15.inc would need to be updated. 5. Note on the incoming replacement of interrupt 20h ---------------------------------------------------- LTH is currently working on the specifications to replace the interrupt 20h with a call table. Since at the time of writing the specs weren't done, I couldn't modify the proposal to make it standard but, I included a sub-service number, which would be used by the memory manager. I'll try to update the proposal as soon as the specifications for the replacement are done. These new specifications would also give the possibility to have multiple memory manager loaded. It is important that if somebody want to develop a memory management module, that the basic services described in this proposal be included, so that an application could transparently be executed under the new memory manager.