Understanding Operating System Design and Implementation

in this lecture we will be discussing about operating system design and implementation so we will be mainly

talking about the design and implementation of operating system and what are the things that we need to keep

in mind if we are designing and implementing an operating system so talking about the design goals the first

problem that we face in design goals are defining the goals and specification now why this is a problem this is a problem

because it is not very easy to specify all the goals and specifications that we need for an operating system that is

because depending on the kind of users and depending on the kind of system requirements that we have there will be

different set of requirements and goals that will be there and it is not actually possible to fulfill all those

goals and requirements so that is why we call it as a problem now talking about some of the requirements which we can

specify two of them are the choice of hardware and then the type of system so by choice of hardware what we mean is

that kind of hardware that we are going to choose on which we are going to build our operating system and then the type

of system so we have discussed about a few kinds of system or few types of system in our previous lectures so it

may include multi processing systems multi tasking systems real-time systems and so on so we can specify the choice

of hardware and in the type of system that we need so these are two requirements which we can actually

specify but beyond this highest level design the requirements may be much harder to specify now beyond this the

kind of requirements that they have it may be difficult to specify and it may be difficult to achieve all of those

requirements now let us see what are the kind of requirements that are there so there are requirements from the users

and then there are requirements from the system so we call them as user goals and system goals so user goals are the

requirements that are there from the users perspective or from the users side and then system goals are the

requirements which are there from the system or from the developers that are developing or designing the system now

let us see what are the requirements that are generally there the user and from the designers so from

the user side we have the user requirements or the user goals now what are the user goals or the requirements

from the user side the user he ones the system to be convenient to use easy to learn and use reliable safe and fast so

these are some of the requirements that are there from the user side now let us see what are the system goals or the

requirements from the designers or the developers which should be there in the system so from the designer side he also

has some requirements so we call it designers or engineers requirements or we call it as the system course so in

the system goals this designer he wants the system to be easy to design and implement maintain and operate and it

should be flexible reliable error-free and efficient so these are some of the requirements from the system side now if

we look at this these are some very general terms or very vague terms so we actually don't have any particular

formula or a particular principle that we can follow in order to achieve all these requirements so there are no

particular rules or there are no particular set of instructions that we need to follow in order to make the

system easy to learn and use or convenient to use or easy to design or something like that so in short we can

say that there is no particular solution to specify or to meet all the requirements that are there in designing

an operating system but there are some principles and rules that are actually followed in order to meet at least some

of the requirements or to make that operating system as good as it can be so these are discussing the subject of

software engineering which you might have studied or which you will be studying in the future so in the

software engineering there are some principles that they follow in order to achieve some of the requirements which

are there or at least most of the requirements that are there in this designing so talking about the software

engineering let us now try to understand the mechanisms and policies involved in that so now we'll be talking about

mechanisms and policies so first let us try to understand what are mechanisms and what are policies so we see that

mechanism determines how to do something while policies determines what will be done so mechanism is determined how to

do something how a particular thing has to be done that is what we mean by mechanism and what will actually be done

that is what we mean by policies now in order to understand this let me take a simple example from our day to day life

so let us say that you are driving a car now for driving a car when you are driving a car there are some mechanisms

going on inside the car which is helping the car to move forward so that is a mechanism that helps in the working of

the car so that is a mechanism now let us say that you are driving your car on a road where there is a rule which says

that you should not exceed the speed of 50 kilometers per hour now that is a policy there is a policy that is a rule

telling you that you should not exceed 50 km/h and then how you maintained at 50 km/h in your car while you are

driving that is the mechanism the working or the mechanism that helps a car in order to maintain that speed and

helps in the working of the car that is the mechanism so I hope that helps us to understand what is mechanism and what is

policies so coming back to our operating system again there is an important principle which says that it is always

good to separate our policy from mechanism one important principle is the separation of policy from mechanism now

why is this required let us come back to our example of the car again now let's say that in the first case you are

having your mechanism and policy separate so let's see why this is good and why this is flexible now you are

driving that same car through another route now and in that other road it says that you should not exceed the speed of

40 kilometers per hour so before you were driving at a speed of 50 kilometers per hour now you are told to drive at 40

kilometers per hour now you need to slow down your speed so for doing that

you don't have to change the mechanism of your car you can just slow down your speed to 40 kilometers per hour but the

mechanism of how the car go it still remains the same so the mechanism is not affected by the change

in policy that we have now let's say that in the other case you are having your mechanism and policy as one unit as

shown over here so if this is the case what happens is that your car is designed to run at 50 km/h now when

there is a new policy which says that you have to slow down to 40 km/h then along with the policy you have to change

the mechanism as well which is a very bad that is because if you have a different policy you have to change the

entire mechanism of your car which is not flexible which is not practical and which is not efficient so from there we

can understand why it is important to have policy and mechanism separate so the change in policy will not affect the

mechanism of your operating system so let us take an example in terms of operating systems because we were

talking about cars till now so let's say that we have a simple example of a resource allocation so we have already

talked about resource allocation so resource allocation means a process needs a particular resource so it

requests for that resource and then the resource has to be allocated to the process now when a process a request for

a resource how that resource will be allocated to the process that is your mechanism and then the policy determines

what will be done the policy will determine whether to allocate the resource to that process or not so that

is your policy so the way of allocating the resource to a process that is your mechanism that should always remain the

same it should not be changed but whether that resource will actually be allocated to the process that will be

determined by the policy so sometimes according to the policy a resource may be allocated or sometimes it may not be

allocated so a change in policy should not affect the mechanism of your operating system that is why we have

this important principle which says it is always good to separate your policy from mechanism alright now we have

talked about designing and we have also talked about mechanisms and policies now after you have done all this after you

have designed your operating system the final thing that you have to do you have to implement your operating

system now let's see how do we implement our operating system so coming to the implementation once an operating system

is designed it must be implemented of course it must be implemented for it to work now traditionally operating systems

have been written in assembly languages so the first operating systems that were there they were mainly written in

assembly languages so if you have used assembly languages or studied about assembly languages you know that it is

not very easy to write assembly languages it is long and it is complicated but now however they are

most commonly written in higher-level languages such as C or C++ but the operating systems that we have now they

are mostly written in higher-level languages such as C or C++ now let us see what are the advantages of a writing

or operating system in higher-level languages and not in assembly language so these are some of the advantages of

writing your operating system in higher-level languages like C or C++ so first one is the code can be written

faster so if you have done assembly language coding then you know that it is not very easy to write in assembly

languages but if you switch to higher-level languages like C or C++ it will be easier and also faster to write

it in this kind of finer level languages and it is more compact it is more compact because you don't have to write

too many things as compared to the assembly languages when you write in higher-level languages and it is easier

to understand and debug so if you are writing your program in higher-level languages it will be easier to

understand even if another person is reading the codes that is written by you we know that it is not very hard to

understand if it is written in C or C++ or something like that and if there are some kind of errors it will be easy to

debug yes it is written in this kind of high level languages and then it says it is easier to port and by easier to port

we mean that it will be easier to port the operating system from one hardware to another hardware

now the problem or disadvantage of writing in assembly language is that if you have written a operating system in

assembly language then that operating system will be hotel only in those hardware which are

fitted with the processors or the CPU families similar to the one in which you have written your operating system like

for example the Microsoft DOS ms-dos which stands for microsoft disk operating system which is an old

operating system it was written in Intel 8088 assembly language and because of this it is available only on the Intel

family of CPUs so since ms-dos was written in the Intel 8088 assembly language so it is supported only on the

Intel family of CPUs so the CPUs from the Intel families are the only ones that supports the operating system

ms-dos but the Linux operating system in contrast it is written mostly in C and is available on a number of different

CPUs including Intel Motorola SPARC M IPs and so on so Linux operating system on the other hand as it is written in C

which is a higher-level language it is available on a variety of CPUs so this is the advantage so that is the example

of portability it is easy to port if you are writing it in higher-level languages alright so that was about the

implementation of your operating system so we discuss about designing policies and mechanisms and implementation of

operating system so when we talk about designing operating system it is a vast task and it is not something that can be

achieved by following some set of rules or there is no particular textbook that will tell you how to do it in order to

specify all the design goals and to achieve all of them so depending on the kind of requirements and the kind of

system that you are developing you will need to use your creativity in order to design it in the best possible way so I

hope that was clear to you that is about the designing and implementation of operating systems so thank you for

watching and see you in the next one [Applause] [Music]