OSDev.org

Well I feel its nice place to discuss my idea of design of OS:
1. Scheduler Will run as ISR for IRQ 0.
2. Round Robin Scheduling will suffice me for time being.
3. Certain Shared libraries will be implemented as Reentrant code and will be accessed by user processes as Call Gates.
4. To allow non-contigous memory allocation and Code relocation i will use paging with segmentation.
5. User processes will address whole 4GB of RAM limit checking and mapping being done in page tables.
6. Code,Data and Stack Segment descriptors for all processes will have base 00000000 and limit FFFFF thus all processes will share the same descriptors in GDT.
7. PCB will be implemeted as TSS for every process.
8. Race conditions will be removed by Queing
I think i should first get advices over these after that i should proceed.

Thanks in Advance

Looks good.

One thing though: you mention paging with segmentation, but also you say in the rest of the post that you effectively disable the segmentation...

Pitchu wrote:Well I feel its nice place to discuss my idea of design of OS:

Agreed. I don't think there's anything in the rest of the post that qualifies for the 'Design and Theory' category - others may disagree

1. Scheduler Will run as ISR for IRQ 0.

Remember that you may have a local APIC timer too. If you have that available, you may like to consider the relative pros and cons of using that for scheduling.

2. Round Robin Scheduling will suffice me for time being.

Absolutely. Start with round robin and make it more complicated once you feel up to it and if your design calls for it.

3. Certain Shared libraries will be implemented as Reentrant code and will be accessed by user processes as Call Gates.

Hmm..I'm really not a big fan of segmentation, so I'll leave this one except to say I plan to provide all my user services via traditional interrupts and syscall/sysenter.

4. To allow non-contigous memory allocation and Code relocation i will use paging with segmentation.

Again - not a big fan of segmentation. Do you ever plan to go 64 bit? If so, forget about the segmentation bit. If you are using paging, what is the additional advantage of using segments over a flat memory model? Doesn't paging + segmentation == a bit of a mess?

5. User processes will address whole 4GB of RAM limit checking and mapping being done in page tables.

Fine, if I understand you. In other words, if a process accesses un-mapped RAM, you get a PFE and decide whether that process is entitled to that memory.

6. Code,Data and Stack Segment descriptors for all processes will have base 00000000 and limit FFFFF thus all processes will share the same descriptors in GDT.

Isn't this a direct contradiction to point 4? That sounds like a flat memory model as opposed to a segmented memory model. Even if you are using a mix of ring 0 and ring 3 segments, if the base is 0 and the limit is 4GiB, you are still using a flat memory model. I suspect this is a terminology issue...

7. PCB will be implemeted as TSS for every process.

It's before 9am and I can't think what you mean by PCB . Again, I would advise that you go with software multitasking rather than using a separate TSS for each process - just have a separate TSS for each CPU. If you plan to go 64 bit in future (or now), you will find that hardware task switching is unsupported.

8. Race conditions will be removed by Queing

There are other people on this forum far better placed than me to discuss race conditions...

Hope some of this helps / makes sense! Some of the above responses involve my personal opinion - if you have a good reason for going against what I have suggested - fine!

Cheers,
Adam

[Edit]Too slow again! Combuster is either a lot quicker than me or I am becoming too verbose in my old age [/Edit]

AJ wrote:

7. PCB will be implemeted as TSS for every process.

It's before 9am and I can't think what you mean by PCB . Again, I would advise that you go with software multitasking rather than using a separate TSS for each process - just have a separate TSS for each CPU. If you plan to go 64 bit in future (or now), you will find that hardware task switching is unsupported.

Process Control Block, http://en.wikipedia.org/wiki/Process_control_block. And yes, I second that software multitasking is probably better in the long run. By making heavy use of functionality specific to an architecture you limit your ability to port it to others in the future.

AlexExtreme wrote:http://en.wikipedia.org/wiki/Process_control_block.

I don't wake up until about 5pm

Re Segmentation... you can do nice tricks with that, but you are aware that this effectively rules out GCC and several other compilers that cannot handle anything but a flat memory model?

Hope some of this helps / makes sense! Some of the above responses involve my personal opinion - if you have a good reason for going against what I have suggested - fine!

Cheers,
Adam

I wish i could have pointed any problem in your quote, i mean it is full of knowledge and pointing anything wrong in it will mean that i hav better knowledge than you......which is not true.
Thanks a lot but I wanna discuss something.

1. Flat Memory Model, Yep u r right. I mean i have to use logical addresses generated by my program as i am using GCC to create simple Flat binaries that demand Code/Data/Stack to point to same area as .com file and what addresses they actually area using will depend upon the pages dynamically allocated to a process and their mapping to frames.I will use these logical addresses to deffine Descriptor values for Code/Data/Stack. In other words, all user processes will share the same set of descriptors and priveledge levels......I think Linux Does so(ref.Galvin).

2.You talked about Local APIC, I googled it but couldnt get basic info about it. Can u tell me something about it.

3. I thing point 1 is not clearer yet;im not able to put it in words....
N proceses N TSS descriptors but only 3 C/D/S Descriptors all having base 0 and limit FFFFFF. But what they are actually accessing depends upon page table entry for each process....
I mean
process | logical_addr | phy_addr
p1 | 0 | f1(say)
p2 | 0 | 73(say)

Hope it wont annoy u.

[/quote]

2.You talked about Local APIC, I googled it but couldnt get basic info about it. Can u tell me something about it.

The APIC is an Advanced Programmable Interrupt Controller. It's like the PIC++. It does everything the PIC can do, but also handles inter-processor interrupts (IPIs) that are the way of communicating between processors in multiprocessing systems.

How could i know whether i have APIC or not considering i hav a single processor machine (say Intel P4) and if it is how can i use it.

Hi,

Have a look at the Intel Multiprocessor Specification. If your CPU is capable of hyperthreading, it has 2 logical cores and therefore a local APIC. There is also some good stuff on the wiki about this (along with information on the IO APIC).

The reason I mentioned the local APIC is that each CPU core has a local APIC timer you can use. As you get one timer per core, it can be very useful for scheduling.

Cheers,
Adam

Thanks
Why can't this simplicity of explanation be induced in books.
Further what care i have to take if my OS will run on MultiCore machine and i have design it for SingleCore machine ; i mean no cosideration of APIC.

Pitchu wrote:Further what care i have to take if my OS will run on MultiCore machine and i have design it for SingleCore machine ; i mean no cosideration of APIC.

Unless you access the APIC and bootstrap the other core(s), you shouldn't even notice them. Your OS will run on one core (the boot processor) just fine, while the others stay idle.

Pitchu wrote: Why can't this simplicity of explanation be induced in books.

Remember that most of the books on OS dev are written by people with CS degrees for people with CS degrees - which I think is forgivable in this context .

Further what care i have to take if my OS will run on MultiCore machine and i have design it for SingleCore machine ; i mean no cosideration of APIC.

Absolutely no problem. The MP specification is set up in such a way that a single core OS will run as if you were on a single core machine. Of course, you still get the benefit of using the Local APIC, if you want. Have a look at this article on OSDever for a breakdown of what the Local APIC is good for in uniprocessor and SMP systems.

Cheers,
Adam

AJ wrote:Doesn't paging + segmentation == a bit of a mess?

Well, it gets a little messier, but it's not that hard to deal with (even with unaware compilers) and since segmentation cannot be disabled in 32 bit mode, why not get some advantages from it :

• Separate data and stack
  Controlled autogrowing stack
  Execute control (no executable data, for instance that's how OpenBSD implements W^X on these machines)
  ...

[quote="pini] since segmentation cannot be disabled in 32 bit mode, why not get some advantages from it :[/quote]

Personally, because I feel I can achieve most of that with paging and that segmentation is already considered pretty 'legacy'. Besides, the main platform for my OS is 64 bit (with a 32 bit backport). If I introduce segmentation in to some ports and just a flat memory model in others, I will end up with a mess on my hands, particularly using a compiler which is not segmentation-aware.

Execute control

..which can be controlled with the NX bit with no need for segmentation.

Cheers,
Adam