paging, multitasking

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
vtfay

paging, multitasking

Post by vtfay »

I want to implement paging and multitasking and malloc function. But dont know which order do ı implement them. If someone advise me an order, Ill be very glad.
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:

Re:paging, multitasking

Post by Solar »

- malloc() without paging (physical memory only);
- multitasking;
- paging daemon;
- malloc() refined with paging.

But that's just me.
Every good solution is obvious once you've found it.
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:paging, multitasking

Post by Pype.Clicker »

(k)malloc should first, imho. without a dynamic memory allocator, handling paging & multitasking could be pretty hard (or maybe that's just my programming style that makes me need it ...).

Depending on what exactly you mean with 'paging' (i.e. is it just setting paging up and giving new physical frames on demand as long as there's no lack for those pages, or do you also include duplication of the address space for new processes), it should come either before or after, but imho, a bit of basic paging before multitasking will help you providing each task a dedicated stack later, so i would say
  • malloc first
  • paging (just the very needed stuff)
  • multitasking
  • paging (advanced stuff)
kaos

Re:paging, multitasking

Post by kaos »

This is what I'd say:

1. something like sbrk() that you can use temporarily instead of malloc()
2. multitasking
3. physical page->virtual address mapping
4. something like morecore() that uses mapped pages
5. malloc() based on morecore()
6. processes (executable loading, multiple address spaces, etc)
7. virtual memory

I skipped #4 and used ksbrk() instead of kmorecore() in #5. I'm now in the process of writing a kmorecore() that uses mapped pages. You can switch a lot of those steps by using code stubs, etc. Whether or not you will want to do that depends largely on your attention span. I tend to get bored quickly when writing at too high a level of abstraction.

You might also want to write an allocator for returnable buffers, because memory allocated using your kernel memory allocator is probably not going to be swappable and will probably not be returned to memory that can be used for applications. I don't mean that it won't be recycled for kernel use (it should be), but it will probably always be part of kernel space. However, buffers such as those that are used in device drivers should be returned to application space when they are no longer in use. You may want to write some other types of allocators as well.

I'll explain more about this idea if anyone wants to hear it.
Post Reply