馃攳
Operating System Design & Implementation - YouTube
Channel: Neso Academy
[0]
in this lecture we will be discussing
[1]
about operating system design and
[3]
implementation so we will be mainly
[5]
talking about the design and
[7]
implementation of operating system and
[9]
what are the things that we need to keep
[11]
in mind if we are designing and
[13]
implementing an operating system so
[15]
talking about the design goals the first
[17]
problem that we face in design goals are
[19]
defining the goals and specification now
[23]
why this is a problem this is a problem
[25]
because it is not very easy to specify
[28]
all the goals and specifications that we
[30]
need for an operating system that is
[32]
because depending on the kind of users
[34]
and depending on the kind of system
[37]
requirements that we have there will be
[38]
different set of requirements and goals
[41]
that will be there and it is not
[43]
actually possible to fulfill all those
[45]
goals and requirements so that is why we
[48]
call it as a problem now talking about
[50]
some of the requirements which we can
[52]
specify two of them are the choice of
[55]
hardware and then the type of system so
[57]
by choice of hardware what we mean is
[60]
that kind of hardware that we are going
[62]
to choose on which we are going to build
[64]
our operating system and then the type
[67]
of system so we have discussed about a
[69]
few kinds of system or few types of
[71]
system in our previous lectures so it
[74]
may include multi processing systems
[76]
multi tasking systems real-time systems
[78]
and so on so we can specify the choice
[82]
of hardware and in the type of system
[84]
that we need so these are two
[86]
requirements which we can actually
[87]
specify but beyond this highest level
[90]
design the requirements may be much
[92]
harder to specify now beyond this the
[94]
kind of requirements that they have it
[97]
may be difficult to specify and it may
[100]
be difficult to achieve all of those
[101]
requirements now let us see what are the
[103]
kind of requirements that are there so
[106]
there are requirements from the users
[108]
and then there are requirements from the
[110]
system so we call them as user goals and
[112]
system goals so user goals are the
[115]
requirements that are there from the
[116]
users perspective or from the users side
[119]
and then system goals are the
[121]
requirements which are there from the
[123]
system or from the developers that are
[126]
developing or designing the system now
[129]
let us see what are the requirements
[131]
that are generally there
[133]
the user and from the designers so from
[136]
the user side we have the user
[137]
requirements or the user goals now what
[140]
are the user goals or the requirements
[141]
from the user side the user he ones the
[144]
system to be convenient to use easy to
[147]
learn and use reliable safe and fast so
[150]
these are some of the requirements that
[152]
are there from the user side now let us
[155]
see what are the system goals or the
[157]
requirements from the designers or the
[160]
developers which should be there in the
[162]
system so from the designer side he also
[164]
has some requirements so we call it
[167]
designers or engineers requirements or
[169]
we call it as the system course so in
[171]
the system goals this designer he wants
[174]
the system to be easy to design and
[176]
implement maintain and operate and it
[179]
should be flexible reliable error-free
[181]
and efficient so these are some of the
[184]
requirements from the system side now if
[187]
we look at this these are some very
[189]
general terms or very vague terms so we
[193]
actually don't have any particular
[195]
formula or a particular principle that
[197]
we can follow in order to achieve all
[199]
these requirements so there are no
[201]
particular rules or there are no
[203]
particular set of instructions that we
[205]
need to follow in order to make the
[207]
system easy to learn and use or
[209]
convenient to use or easy to design or
[212]
something like that so in short we can
[214]
say that there is no particular solution
[217]
to specify or to meet all the
[220]
requirements that are there in designing
[223]
an operating system but there are some
[226]
principles and rules that are actually
[228]
followed in order to meet at least some
[231]
of the requirements or to make that
[233]
operating system as good as it can be so
[236]
these are discussing the subject of
[238]
software engineering which you might
[240]
have studied or which you will be
[242]
studying in the future so in the
[243]
software engineering there are some
[245]
principles that they follow in order to
[247]
achieve some of the requirements which
[249]
are there or at least most of the
[251]
requirements that are there in this
[252]
designing so talking about the software
[255]
engineering let us now try to understand
[257]
the mechanisms and policies involved in
[260]
that so now we'll be talking about
[261]
mechanisms and policies so first let us
[264]
try to understand what are mechanisms
[267]
and what are policies so we see that
[269]
mechanism determines how to do something
[272]
while policies determines what will be
[275]
done so mechanism is determined how to
[277]
do something how a particular thing has
[279]
to be done that is what we mean by
[281]
mechanism and what will actually be done
[284]
that is what we mean by policies now in
[288]
order to understand this let me take a
[290]
simple example from our day to day life
[291]
so let us say that you are driving a car
[293]
now for driving a car when you are
[296]
driving a car there are some mechanisms
[298]
going on inside the car which is helping
[301]
the car to move forward so that is a
[303]
mechanism that helps in the working of
[306]
the car so that is a mechanism now let
[308]
us say that you are driving your car on
[310]
a road where there is a rule which says
[313]
that you should not exceed the speed of
[316]
50 kilometers per hour now that is a
[319]
policy there is a policy that is a rule
[321]
telling you that you should not exceed
[323]
50 km/h and then how you maintained at
[327]
50 km/h in your car while you are
[330]
driving that is the mechanism the
[332]
working or the mechanism that helps a
[334]
car in order to maintain that speed and
[337]
helps in the working of the car that is
[339]
the mechanism so I hope that helps us to
[343]
understand what is mechanism and what is
[344]
policies so coming back to our operating
[347]
system again there is an important
[349]
principle which says that it is always
[351]
good to separate our policy from
[354]
mechanism one important principle is the
[356]
separation of policy from mechanism now
[359]
why is this required let us come back to
[361]
our example of the car again now let's
[364]
say that in the first case you are
[366]
having your mechanism and policy
[368]
separate so let's see why this is good
[370]
and why this is flexible now you are
[372]
driving that same car through another
[374]
route now and in that other road it says
[376]
that you should not exceed the speed of
[379]
40 kilometers per hour so before you
[381]
were driving at a speed of 50 kilometers
[383]
per hour now you are told to drive at 40
[387]
kilometers per hour
[388]
now you need to slow down your speed so
[390]
for doing that
[391]
you don't have to change the mechanism
[393]
of your car you can just slow down your
[396]
speed to 40 kilometers per hour but the
[399]
mechanism of how the car go
[400]
it still remains the same so the
[403]
mechanism is not affected by the change
[405]
in policy that we have now let's say
[408]
that in the other case you are having
[410]
your mechanism and policy as one unit as
[412]
shown over here so if this is the case
[415]
what happens is that your car is
[417]
designed to run at 50 km/h now when
[421]
there is a new policy which says that
[422]
you have to slow down to 40 km/h then
[426]
along with the policy you have to change
[428]
the mechanism as well which is a very
[431]
bad that is because if you have a
[434]
different policy you have to change the
[435]
entire mechanism of your car which is
[437]
not flexible which is not practical and
[439]
which is not efficient so from there we
[442]
can understand why it is important to
[444]
have policy and mechanism separate so
[447]
the change in policy will not affect the
[449]
mechanism of your operating system so
[452]
let us take an example in terms of
[453]
operating systems because we were
[455]
talking about cars till now so let's say
[457]
that we have a simple example of a
[459]
resource allocation so we have already
[461]
talked about resource allocation so
[463]
resource allocation means a process
[465]
needs a particular resource so it
[467]
requests for that resource and then the
[469]
resource has to be allocated to the
[471]
process now when a process a request for
[474]
a resource how that resource will be
[477]
allocated to the process that is your
[479]
mechanism and then the policy determines
[482]
what will be done the policy will
[483]
determine whether to allocate the
[486]
resource to that process or not so that
[489]
is your policy so the way of allocating
[492]
the resource to a process that is your
[494]
mechanism that should always remain the
[496]
same it should not be changed but
[498]
whether that resource will actually be
[501]
allocated to the process that will be
[503]
determined by the policy so sometimes
[506]
according to the policy a resource may
[508]
be allocated or sometimes it may not be
[510]
allocated so a change in policy should
[512]
not affect the mechanism of your
[515]
operating system that is why we have
[517]
this important principle which says it
[519]
is always good to separate your policy
[522]
from mechanism alright now we have
[524]
talked about designing and we have also
[527]
talked about mechanisms and policies now
[529]
after you have done all this after you
[531]
have designed your operating system the
[533]
final thing that you have to do
[534]
you have to implement your operating
[537]
system now let's see how do we implement
[539]
our operating system so coming to the
[541]
implementation once an operating system
[543]
is designed it must be implemented of
[545]
course it must be implemented for it to
[547]
work now traditionally operating systems
[550]
have been written in assembly languages
[552]
so the first operating systems that were
[554]
there they were mainly written in
[556]
assembly languages so if you have used
[558]
assembly languages or studied about
[560]
assembly languages you know that it is
[562]
not very easy to write assembly
[564]
languages it is long and it is
[566]
complicated but now however they are
[569]
most commonly written in higher-level
[571]
languages such as C or C++ but the
[574]
operating systems that we have now they
[576]
are mostly written in higher-level
[578]
languages such as C or C++ now let us
[581]
see what are the advantages of a writing
[583]
or operating system in higher-level
[585]
languages and not in assembly language
[587]
so these are some of the advantages of
[590]
writing your operating system in
[591]
higher-level languages like C or C++ so
[594]
first one is the code can be written
[596]
faster so if you have done assembly
[598]
language coding then you know that it is
[600]
not very easy to write in assembly
[602]
languages but if you switch to
[604]
higher-level languages like C or C++ it
[608]
will be easier and also faster to write
[610]
it in this kind of finer level languages
[612]
and it is more compact it is more
[615]
compact because you don't have to write
[617]
too many things as compared to the
[619]
assembly languages when you write in
[621]
higher-level languages and it is easier
[623]
to understand and debug so if you are
[626]
writing your program in higher-level
[627]
languages it will be easier to
[629]
understand even if another person is
[632]
reading the codes that is written by you
[633]
we know that it is not very hard to
[636]
understand if it is written in C or C++
[639]
or something like that and if there are
[641]
some kind of errors it will be easy to
[643]
debug yes it is written in this kind of
[646]
high level languages and then it says it
[649]
is easier to port and by easier to port
[651]
we mean that it will be easier to port
[655]
the operating system from one hardware
[657]
to another hardware
[658]
now the problem or disadvantage of
[661]
writing in assembly language is that if
[662]
you have written a operating system in
[665]
assembly language then that operating
[667]
system will be
[668]
hotel only in those hardware which are
[671]
fitted with the processors or the CPU
[674]
families similar to the one in which you
[676]
have written your operating system like
[678]
for example the Microsoft DOS ms-dos
[682]
which stands for microsoft disk
[684]
operating system which is an old
[685]
operating system it was written in Intel
[688]
8088 assembly language and because of
[691]
this it is available only on the Intel
[694]
family of CPUs so since ms-dos was
[696]
written in the Intel 8088 assembly
[699]
language so it is supported only on the
[702]
Intel family of CPUs so the CPUs from
[707]
the Intel families are the only ones
[708]
that supports the operating system
[710]
ms-dos but the Linux operating system in
[713]
contrast it is written mostly in C and
[716]
is available on a number of different
[718]
CPUs including Intel Motorola SPARC M
[722]
IPs and so on so Linux operating system
[725]
on the other hand as it is written in C
[728]
which is a higher-level language it is
[730]
available on a variety of CPUs so this
[733]
is the advantage so that is the example
[735]
of portability it is easy to port if you
[738]
are writing it in higher-level languages
[740]
alright so that was about the
[742]
implementation of your operating system
[744]
so we discuss about designing policies
[747]
and mechanisms and implementation of
[750]
operating system so when we talk about
[752]
designing operating system it is a vast
[754]
task and it is not something that can be
[756]
achieved by following some set of rules
[758]
or there is no particular textbook that
[760]
will tell you how to do it in order to
[763]
specify all the design goals and to
[765]
achieve all of them so depending on the
[767]
kind of requirements and the kind of
[769]
system that you are developing you will
[771]
need to use your creativity in order to
[773]
design it in the best possible way so I
[776]
hope that was clear to you that is about
[778]
the designing and implementation of
[781]
operating systems so thank you for
[783]
watching and see you in the next one
[785]
[Applause]
[787]
[Music]
Most Recent Videos:
You can go back to the homepage right here: Homepage