Operating System Design & Implementation
Summary
TLDRThis lecture delves into the complexities of operating system design and implementation, highlighting the challenges of defining goals and specifications due to diverse user and system requirements. It emphasizes the importance of distinguishing between user goals, such as convenience and reliability, and system goals, like ease of design and efficiency. The talk underscores the principle of separating policy from mechanism for flexibility and the shift from assembly languages to higher-level languages like C or C++ for implementation, citing advantages such as faster code writing, easier debugging, and improved portability across different CPUs.
Takeaways
- 🔍 The lecture focuses on the intricate process of operating system design and implementation, highlighting the challenges and considerations involved.
- 🎯 The first challenge in designing an operating system is defining clear goals and specifications, which is difficult due to the diverse requirements of users and systems.
- 🛠️ Hardware selection and the type of system (e.g., multiprocessing, multitasking, real-time) are two key requirements that can be specified in the design phase.
- 🤔 The distinction between user goals and system goals is crucial, with users typically seeking convenience, ease of use, reliability, safety, and speed, while designers aim for ease of design, implementation, maintenance, flexibility, and efficiency.
- 📚 There are no specific formulas or principles to achieve all design requirements, but principles from 'Software Engineering' can guide the process to meet some of these requirements.
- 🔄 The importance of separating policy from mechanism in operating system design is emphasized for flexibility and practicality, allowing changes in policy without altering the underlying mechanisms.
- 🚗 A real-world analogy of driving a car is used to illustrate the concept of mechanisms and policies, showing how changing policies should not necessitate changes in mechanisms.
- 💡 The resource allocation process within an operating system is an example where mechanisms determine how resources are allocated, while policies decide whether to allocate them.
- 🛑 Historically, operating systems were written in assembly languages, but modern systems are predominantly written in higher-level languages like C or C++ for ease of development and portability.
- ✍️ Writing an operating system in a higher-level language offers advantages such as faster code writing, compactness, ease of understanding and debugging, and improved portability across different hardware.
- 🌐 The portability advantage is exemplified by the Linux operating system, which is written in C and available on a variety of CPUs, contrasting with MS-DOS, which is limited to Intel CPUs due to its assembly language origins.
Q & A
What is the primary challenge in defining design goals for an operating system?
-The primary challenge in defining design goals for an operating system is specifying all the goals and requirements, as they can vary greatly depending on user and system requirements. It is often not possible to fulfill all these diverse goals and requirements.
What are the two specific requirements that can be specified when designing an operating system?
-The two specific requirements that can be specified when designing an operating system are the choice of hardware on which the operating system will be built and the type of system, such as multiprocessing, multitasking, or real-time systems.
What is the difference between user goals and system goals in the context of operating system design?
-User goals are the requirements from the user's perspective, focusing on aspects like convenience, ease of use, reliability, safety, and speed. System goals, on the other hand, are the requirements from the system or developer's side, emphasizing ease of design, implementation, maintenance, operability, flexibility, reliability, error-free operation, and efficiency.
Why is it difficult to achieve all user and system requirements when designing an operating system?
-Achieving all user and system requirements is difficult because there are often conflicting priorities and constraints. The complexity of the system and the need to balance various goals, such as performance and reliability, make it challenging to satisfy every requirement.
What is the importance of separating policy from mechanism in operating system design?
-Separating policy from mechanism in operating system design is important because it allows for flexibility and adaptability. Changes in policy should not affect the underlying mechanisms, making it easier to adapt to new requirements or rules without having to redesign the system's core functionality.
Can you provide an example to illustrate the concept of separating policy from mechanism?
-An example given in the script is driving a car. The mechanism is the internal workings of the car that help it move forward, while the policy is the speed limit rule, such as not exceeding 50 kilometers per hour. Changing the policy (e.g., reducing the speed limit to 40 km/h) should not require a change in the car's mechanism.
What are some advantages of writing an operating system in higher-level languages like C or C++ instead of assembly language?
-Writing an operating system in higher-level languages like C or C++ allows for faster code development, more compact and understandable code, easier debugging, and improved portability across different hardware platforms.
Why is portability an important consideration when choosing a programming language for operating system development?
-Portability is important because it allows the operating system to run on a variety of hardware platforms. This flexibility makes the operating system more versatile and accessible to a wider range of users and devices.
How does the script illustrate the concept of portability in the context of operating systems?
-The script uses the example of MS-DOS, which was written in Intel 8088 assembly language and is therefore only supported on Intel CPUs, versus Linux, which is written in C and can run on a variety of CPUs, demonstrating the advantage of using higher-level languages for greater portability.
What are some of the general terms or vague terms mentioned in the script that describe user and system goals for an operating system?
-Some of the general terms or vague terms mentioned include 'convenient to use,' 'easy to learn and use,' 'reliable,' 'safe,' 'fast,' 'easy to design,' 'implement,' 'maintain,' 'operate,' 'flexible,' 'error-free,' and 'efficient.'
What does the script suggest about the process of designing an operating system?
-The script suggests that designing an operating system is a vast and complex task that cannot be achieved by simply following a set of rules or guidelines. It requires creativity and an understanding of the specific requirements and goals of the system being developed.
Outlines
🛠️ Operating System Design Challenges
The first paragraph introduces the complexities of operating system design and implementation. It discusses the difficulty in defining clear goals and specifications due to varying user and system requirements. The paragraph highlights the importance of choosing the right hardware and system types, such as multiprocessing or multitasking systems. It also differentiates between user goals, which include convenience, reliability, and speed, and system goals, which focus on ease of design, maintenance, and efficiency. The lack of a one-size-fits-all solution is emphasized, suggesting that principles from software engineering can guide the design process, including the distinction between mechanisms, which determine how tasks are performed, and policies, which decide what tasks are carried out.
🚗 Separating Policy and Mechanism in Design
This paragraph uses the analogy of driving a car to explain the concept of policy and mechanism separation in operating system design. It argues that separating these two aspects allows for flexibility and adaptability to changes in policy without altering the underlying mechanisms. The paragraph illustrates this with examples of speed limits and how they affect the car's operation. The principle is then applied to operating systems, emphasizing the importance of keeping the resource allocation mechanism constant while allowing policies to determine the allocation decisions. This approach ensures that changes in policy do not necessitate changes to the system's core mechanisms, promoting a more efficient and maintainable design.
💻 Implementing Operating Systems with High-Level Languages
The final paragraph shifts focus to the implementation of operating systems, noting the transition from assembly languages to higher-level languages like C or C++. It outlines the advantages of using high-level languages, such as faster code writing, increased compactness, ease of understanding and debugging, and improved portability across different hardware platforms. The paragraph contrasts the limitations of assembly language-based systems, which are often restricted to specific hardware, with the broader compatibility of high-level language-based systems, exemplified by the Linux operating system. The summary concludes by emphasizing the creative and requirement-driven nature of operating system design, which cannot be fully encapsulated by a set of rules or a textbook approach.
Mindmap
Keywords
💡Operating System
💡Design Goals
💡Hardware Choice
💡System Types
💡User Goals
💡System Goals
💡Mechanism
💡Policy
💡Separation of Policy and Mechanism
💡Implementation
💡Portability
Highlights
Lecture focuses on operating system design and implementation, discussing key considerations in the process.
Design goals are challenging due to the difficulty in specifying all goals and requirements for an operating system.
Different sets of requirements and goals exist based on user and system needs, making it impossible to fulfill all.
Hardware choice and system type are two requirements that can be specified in operating system design.
User goals include the desire for a system that is convenient, easy to learn and use, reliable, safe, and fast.
System goals from a designer's perspective include ease of design, implementation, maintenance, operation, flexibility, reliability, error-free operation, and efficiency.
There is no specific formula to achieve all design requirements, highlighting the need for creativity and principles from Software Engineering.
Mechanisms determine how to do something, while policies determine what will be done in the context of operating systems.
The separation of policy from mechanism is crucial for flexibility and practicality in operating system design.
An example of policy and mechanism in everyday life is driving a car with speed limits as policies and car mechanisms to maintain speed.
The importance of separating policy and mechanism is further illustrated with the example of changing speed limits without altering the car's design.
Resource allocation in operating systems is used as an example to explain the distinction between mechanism and policy.
Operating systems are traditionally written in assembly languages, but modern systems are commonly implemented in higher-level languages like C or C++.
Advantages of higher-level languages include faster code writing, compactness, ease of understanding, and easier debugging.
Portability is a significant benefit of using higher-level languages, allowing an operating system to work on various CPUs.
MS-DOS was written in assembly language and is limited to Intel CPUs, contrasting with Linux, which is written in C and supports multiple CPUs.
Designing an operating system is a vast task that requires creativity and cannot be fully guided by a set of rules or a textbook.
Transcripts
In this lecture, we will discuss operating system design and implementation.
So, we will be mainly talk about
the design and implementation of the 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 is
defining the goals and specifications.
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 users and system requirements that we have,
there may be different sets 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 types of the system.
So, by the choice of hardware
what we mean is the kind of hardware that we are going to choose
on which we are going to build our operating system.
And then the type of the system.
So, we have discussed a few kinds of systems and few types of systems
in our previous lectures.
It includes multiprocessing system, multitasking systems,
real-time system and so on.
So, we can specify the choice of hardware
and the type of system that we need.
So, these are two requirements that 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
may be difficult to specify or difficult to achieve all.
Now, let us see what are the kinds of requirements that are there.
So, there are requirements from the users,
and then from the system.
So, we call them as user goals and system goals.
So, user goals are the requirements
that are there from the user perspective or from the user 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 from the users
and from the designers.
So, from the user's side, we have the user requirement or the user goals.
Now, what are the user goals or the requirements from the user side?
the user wants 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 calls
or the requirements from the designers and the developers for the system.
So, from the designer side, he also have some requirements.
So, we call it as the designer's or engineer's requirements or the system goals.
So, in this system goals,
the designer wants the system to be easy to design, implement,
maintain, and operate and it should be flexible, reliable, error free and efficient.
So these are some requirements from the system side.
Now, if we look at this
these are some very general terms or vague terms.
So, we actually don't have any particular formula or principle that we can follow,
in order to achieve all these requirements.
So, there are no particular rules or set of instructions we need to follow
in order to make the system easy to learn and use or convenient or easy to design.
So, in short we can say that,
there is no particular solution to specify or meet
all the requirements in designing an operating system.
But there are some principles and rules that actually followed
in order to meet at least some of the requirements
and to make the operating system as good as it can be.
So, these are discussed in the subject 'Software Engineering'
which you might have studied or which you will be studying in the future.
In the 'Software Engineering' there are some principles that
they follow in order to achieve
most of the requirements that are there in designing.
So, talking about the software engineering
let us now try to understand the mechanism and policies involved in that.
So, now we will be talking about mechanism and policies.
So, first let us try to understand, what are mechanisms?
and what are policies?
So we see that.
Mechanisms determine how to do something
while policies determine what will be done.
So, mechanisms determine
how to do something or 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, when you are driving a car
there is some mechanism going on inside the car
which is helping the car to move forward.
So, that is the 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 route
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 or rule telling you that
you should not exceed 50 kilometers per hour.
And then how you maintained that 50 kilometers per hour in your car
while you are driving, that is the mechanism.
The working or the mechanism that helps the 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 the operating system again.
There is an important principle which says that
It is always good to separate our polices from mechanism.
One important is the separation of policy from mechanism.
Now, why is this required?
Let us again comeback to our example of the car.
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 the same car through another route.
And that other route 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 sped to 40 kilometer per hour
but the mechanism of how the car works still remain the same.
So, the mechanism is not affected by the change in policies that we have.
Now, let's say that in the other case,
you are having your mechanism and policies as one unit as shown over here.
So, if this is the case, what happen is that
your car is design to run at 50 kilometers per hour.
Now, when there is a new policy which says that
you have to slow down to 40 kilometers per hour.
Then along with the policy you have to change the mechanism as well.
Which is very bad.
That is because if you have a different policy
you have to change the entire mechanism of your car
which is neither flexible, nor practical, nor efficient.
So, from there we can understand why it is important to have
policy and mechanism separate.
So, the change in policy will not effect the mechanism of your operating system.
So, let us take an example in terms of operating system
because we were talking about car till now.
So, let's say that we have a simple example of resource allocation.
So, we have already talked about resource allocation.
So, resource allocation means a process needs a particular resource,
so it request for that resource
and then the resource has to be allocated to the process.
Now, when a process request for a resource.
how the 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 is your mechanism
should always remain the same.
It should not be changed.
But whether the resource will actually be allocated to the process
that will be determine by the policy.
So, sometimes according to the policy
a resource may be allocated or sometimes it may not be.
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 the mechanism.
Alright!
Now, we have talked about designing, mechanism and also policies.
Now, after you have done all these,
after you have designed your operating system,
the final thing that you have to do is 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 to work.
Now, traditionally operating system
have been written in assembly languages.
So, the first operating systems were written in assembly languages.
So, if you have used or studied the assembly languages,
you know that it is not very easy to write them.
It is long and complicated.
But now however they are most commonly written in higher-level languages
such as C or C++.
But the operating system 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 writing
the operating system in higher level languages and not n assembly language.
So these are some of the advantages of writing your operating system
in higher level languages like C or C++.
So, the 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 in this kinds of higher level languages.
Higher level languages are more compact because
you don't have to write too many things
as compared to the assembly 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 an 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, C++ or something like that.
And if there are some kind of errors, it will be easy to debug,
if this is written in these kinds of high level languages.
And then it says it is easier to port.
And by easier to port we mean that
it wll be easier to port the operating system from one hardware to another.
Now, the problems or disadvantages of writing in assembly languages is that
if you have written an operating system in assembly language,
then that operating system will be supported only in those hardware
which are fitted with the processor or the CPU families
similar to the one in which you have written your operating system.
Like for example -
The Microsoft DOS(MS-DOS), stands for Microsoft Disc 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
it is supported only on the Intel family of CPUs.
So, the CPUs from the Intel family's are the only one that supports the MS-DOS.
But, the Linux operating system in contrast is mostly written in C
and is available on number of different CPUs including Intel, Motorola,
Spark, MIPS and so on.
So, Linux operating system as written in C, which is a higher level language
It is available on variety of CPUs.
So, this is the advantage.
So, that is the example of portability.
It is easy to port if you are writing in higher level languages.
Alright!
So, that was about the implementation of your operating system.
So, we discussed about designing, policy, mechanism,
and implementation of operating system.
So, when we talk about designing of the 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 text book 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 the 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 was about the designing and implementation of the operating system.
So, Thank you for watching and see you in the next one.
5.0 / 5 (0 votes)