paging, multitasking
paging, multitasking
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.
Re:paging, multitasking
- malloc() without paging (physical memory only);
- multitasking;
- paging daemon;
- malloc() refined with paging.
But that's just me.
- multitasking;
- paging daemon;
- malloc() refined with paging.
But that's just me.
Every good solution is obvious once you've found it.
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:paging, multitasking
(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
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)
Re:paging, multitasking
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.
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.