Operating System Design & Implementation

Neso Academy
19 Apr 201813:16

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

00:00

🛠️ 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.

05:01

🚗 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.

10:04

💻 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

An operating system (OS) is the software that manages computer hardware, software resources, and provides essential services for computer programs. It is the core component of a computer system, acting as an interface between the user and the computer hardware. In the video, the design and implementation of an operating system is the central theme, with discussions on how to approach the creation of an OS that meets various user and system requirements.

💡Design Goals

Design goals refer to the objectives or targets set during the planning phase of a project. In the context of the video, defining the design goals for an operating system is highlighted as a challenging task because it involves specifying all the necessary goals and requirements that may vary based on user needs and system capabilities. The script emphasizes that it's not always possible to fulfill every goal due to conflicting requirements.

💡Hardware Choice

Hardware choice pertains to the selection of the physical components on which the operating system will be built. The video mentions that the type of hardware chosen can significantly influence the design and capabilities of an operating system. It's one of the early decisions in the OS development process that can affect performance, compatibility, and features.

💡System Types

System types categorize the nature and capabilities of a computer system. The script refers to various system types such as multiprocessing, multitasking, and real-time systems. Each type has specific characteristics that influence the design and implementation of the operating system, such as how processes are managed and how tasks are scheduled.

💡User Goals

User goals represent the requirements or desires from the end-user's perspective. The video lists user goals for an operating system as being convenient to use, easy to learn and use, reliable, safe, and fast. These goals guide the design to ensure the OS meets the expectations and needs of its users.

💡System Goals

System goals are the objectives set by the designers or engineers for the operating system itself. According to the script, system goals include making the OS easy to design, implement, maintain, and operate, as well as ensuring it is flexible, reliable, error-free, and efficient. These goals are crucial for the long-term success and sustainability of the OS.

💡Mechanism

In the context of the video, a mechanism is defined as the 'how' of a process or function within an operating system. It refers to the methods or techniques used to implement a particular feature or process, such as how resources are allocated to a process. The script uses the analogy of a car's internal workings to illustrate the concept of mechanisms in operating systems.

💡Policy

Policy, as discussed in the video, determines the 'what' in the context of operating system decisions. It refers to the rules or guidelines that dictate the actions to be taken, such as whether to allocate a resource to a process. Policies are distinct from mechanisms and can change without affecting the underlying implementation details.

💡Separation of Policy and Mechanism

The principle of separating policy from mechanism is emphasized in the video as a key design approach. It advocates for keeping the decision-making process (policy) separate from the implementation details (mechanism). This separation allows for greater flexibility and adaptability, as changes in policy do not necessitate changes in the underlying mechanisms, as illustrated with the car speed limit analogy.

💡Implementation

Implementation in the video refers to the process of bringing the designed operating system to life through coding and development. Historically, operating systems were implemented in assembly languages, but the script notes a shift towards higher-level languages like C or C++ for ease of development, readability, and portability.

💡Portability

Portability is the ability of an operating system to run on different types of hardware platforms. The video highlights the advantages of writing an OS in higher-level languages, which facilitates easier porting compared to assembly languages. The script contrasts MS-DOS, which is limited to Intel CPUs due to its assembly language implementation, with Linux, which is written in C and supports a variety of CPUs.

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

play00:00

In this lecture, we will discuss operating system design and implementation.

play00:04

So, we will be mainly talk about

play00:06

the design and implementation of the operating system.

play00:09

And what are the things that we need to keep in mind

play00:12

if we are designing and implementing an operating system.

play00:15

So, talking about the design goals,

play00:17

the first problem that we face in design goals is

play00:20

defining the goals and specifications.

play00:22

Now, why this is a problem?

play00:24

This is a problem because, it is not very easy to specify

play00:28

all the goals and specifications that we need for an operating system.

play00:32

That is because

play00:33

depending on the users and system requirements that we have,

play00:38

there may be different sets of requirements

play00:40

and goals that will be there.

play00:42

And it is not actually possible to fulfill all those goals and requirements.

play00:47

So, that is why we call it as a problem.

play00:49

Now, talking about some of the requirements which we can specify

play00:53

two of them are the choice of hardware and then the types of the system.

play00:57

So, by the choice of hardware

play00:59

what we mean is the kind of hardware that we are going to choose

play01:03

on which we are going to build our operating system.

play01:05

And then the type of the system.

play01:08

So, we have discussed a few kinds of systems and few types of systems

play01:12

in our previous lectures.

play01:13

It includes multiprocessing system, multitasking systems,

play01:17

real-time system and so on.

play01:19

So, we can specify the choice of hardware

play01:23

and the type of system that we need.

play01:25

So, these are two requirements that we can actually specify.

play01:28

But beyond this highest level design

play01:31

the requirements may be much harder to specify.

play01:33

Now, beyond this, the kind of requirements that they have

play01:37

may be difficult to specify or difficult to achieve all.

play01:42

Now, let us see what are the kinds of requirements that are there.

play01:45

So, there are requirements from the users,

play01:48

and then from the system.

play01:50

So, we call them as user goals and system goals.

play01:53

So, user goals are the requirements

play01:56

that are there from the user perspective or from the user side.

play02:00

And then system goals are the requirements

play02:02

which are there from the system or from the developers

play02:06

that are developing or designing the system.

play02:08

Now, let us see, what are the requirements that are generally there from the users

play02:13

and from the designers.

play02:15

So, from the user's side, we have the user requirement or the user goals.

play02:19

Now, what are the user goals or the requirements from the user side?

play02:22

the user wants the system to be convenient to use,

play02:27

easy to learn and use, reliable, safe and fast.

play02:30

So, these are some of the requirements that are there from the user side.

play02:34

Now, let us see what are the system calls

play02:37

or the requirements from the designers and the developers for the system.

play02:43

So, from the designer side, he also have some requirements.

play02:46

So, we call it as the designer's or engineer's requirements or the system goals.

play02:51

So, in this system goals,

play02:52

the designer wants the system to be easy to design, implement,

play02:57

maintain, and operate and it should be flexible, reliable, error free and efficient.

play03:03

So these are some requirements from the system side.

play03:06

Now, if we look at this

play03:08

these are some very general terms or vague terms.

play03:12

So, we actually don't have any particular formula or principle that we can follow,

play03:18

in order to achieve all these requirements.

play03:21

So, there are no particular rules or set of instructions we need to follow

play03:26

in order to make the system easy to learn and use or convenient or easy to design.

play03:33

So, in short we can say that,

play03:35

there is no particular solution to specify or meet

play03:40

all the requirements in designing an operating system.

play03:44

But there are some principles and rules that actually followed

play03:48

in order to meet at least some of the requirements

play03:52

and to make the operating system as good as it can be.

play03:55

So, these are discussed in the subject 'Software Engineering'

play03:59

which you might have studied or which you will be studying in the future.

play04:03

In the 'Software Engineering' there are some principles that

play04:06

they follow in order to achieve

play04:08

most of the requirements that are there in designing.

play04:14

So, talking about the software engineering

play04:16

let us now try to understand the mechanism and policies involved in that.

play04:20

So, now we will be talking about mechanism and policies.

play04:23

So, first let us try to understand, what are mechanisms?

play04:27

and what are policies?

play04:28

So we see that.

play04:29

Mechanisms determine how to do something

play04:32

while policies determine what will be done.

play04:35

So, mechanisms determine

play04:37

how to do something or how a particular thing has to be done.

play04:40

That is what we mean by mechanism.

play04:42

And, what will actually be done

play04:44

that is what we mean by policies.

play04:47

Now, in order to understand this

play04:49

let me take a simple example from our day to day life.

play04:52

So, let us say that you are driving a car.

play04:54

Now, when you are driving a car

play04:57

there is some mechanism going on inside the car

play05:00

which is helping the car to move forward.

play05:03

So, that is the mechanism that helps in the working of the car.

play05:06

So, that is a mechanism.

play05:08

Now let us say that you are driving your car on a route

play05:12

where there is a rule which says that

play05:14

you should not exceed the speed of 50 kilometers per hour.

play05:18

Now, that is a policy.

play05:20

There is a policy or rule telling you that

play05:22

you should not exceed 50 kilometers per hour.

play05:25

And then how you maintained that 50 kilometers per hour in your car

play05:29

while you are driving, that is the mechanism.

play05:32

The working or the mechanism that helps the car in order to maintain that speed

play05:37

and helps in the working of the car, that is the mechanism.

play05:41

So, I hope that helps us to understand what is mechanism and what is policies.

play05:45

so, coming back to the operating system again.

play05:48

There is an important principle which says that

play05:50

It is always good to separate our polices from mechanism.

play05:55

One important is the separation of policy from mechanism.

play05:59

Now, why is this required?

play06:00

Let us again comeback to our example of the car.

play06:03

Now let's say that in the first case

play06:06

you are having your mechanism and policy separate.

play06:09

So, let's see why this is good and why this is flexible?

play06:12

Now you are driving the same car through another route.

play06:15

And that other route says that

play06:17

you should not exceed the speed of 40 kilometers per hour.

play06:21

So, before you were driving at a speed of 50 kilometers per hour.

play06:24

Now, you are told to drive at 40 kilometers per hour.

play06:28

Now, you need to slow down your speed.

play06:30

So, for doing that you don't have to change the mechanism of your car,

play06:34

you can just slow down your sped to 40 kilometer per hour

play06:38

but the mechanism of how the car works still remain the same.

play06:42

So, the mechanism is not affected by the change in policies that we have.

play06:47

Now, let's say that in the other case,

play06:49

you are having your mechanism and policies as one unit as shown over here.

play06:53

So, if this is the case, what happen is that

play06:56

your car is design to run at 50 kilometers per hour.

play07:00

Now, when there is a new policy which says that

play07:03

you have to slow down to 40 kilometers per hour.

play07:06

Then along with the policy you have to change the mechanism as well.

play07:10

Which is very bad.

play07:12

That is because if you have a different policy

play07:15

you have to change the entire mechanism of your car

play07:17

which is neither flexible, nor practical, nor efficient.

play07:21

So, from there we can understand why it is important to have

play07:24

policy and mechanism separate.

play07:27

So, the change in policy will not effect the mechanism of your operating system.

play07:32

So, let us take an example in terms of operating system

play07:34

because we were talking about car till now.

play07:36

So, let's say that we have a simple example of resource allocation.

play07:41

So, we have already talked about resource allocation.

play07:43

So, resource allocation means a process needs a particular resource,

play07:47

so it request for that resource

play07:49

and then the resource has to be allocated to the process.

play07:52

Now, when a process request for a resource.

play07:55

how the resource will be allocated to the process?

play07:58

That is your mechanism.

play08:00

And then the policy determines what will be done.

play08:03

The policy will determine

play08:04

whether to allocate the resource to that process or not.

play08:08

So that is your policy.

play08:10

So, the way of allocating the resource to a process is your mechanism

play08:15

should always remain the same.

play08:17

It should not be changed.

play08:18

But whether the resource will actually be allocated to the process

play08:22

that will be determine by the policy.

play08:25

So, sometimes according to the policy

play08:27

a resource may be allocated or sometimes it may not be.

play08:30

So, a change in policy should not affect the mechanism of your operating system.

play08:36

That is why we have this important principle which says

play08:39

it is always good to separate your policy from the mechanism.

play08:43

Alright!

play08:44

Now, we have talked about designing, mechanism and also policies.

play08:49

Now, after you have done all these,

play08:51

after you have designed your operating system,

play08:53

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

play08:57

Now, let's see how do we implement our operating system.

play09:00

So, coming to the implementation.

play09:02

Once an operating system is designed, it must be implemented to work.

play09:07

Now, traditionally operating system

play09:10

have been written in assembly languages.

play09:12

So, the first operating systems were written in assembly languages.

play09:17

So, if you have used or studied the assembly languages,

play09:21

you know that it is not very easy to write them.

play09:25

It is long and complicated.

play09:27

But now however they are most commonly written in higher-level languages

play09:32

such as C or C++.

play09:34

But the operating system that we have now

play09:36

they are mostly written in higher level languages such as C or C++.

play09:41

Now, let us see what are the advantages of writing

play09:43

the operating system in higher level languages and not n assembly language.

play09:48

So these are some of the advantages of writing your operating system

play09:51

in higher level languages like C or C++.

play09:54

So, the first one is the code can be written faster.

play09:57

So, if you have done assembly language coding

play09:59

then you know that it is not very easy to write in assembly languages.

play10:03

But if you switch to higher level languages like C or C++,

play10:07

it will be easier and also faster to write in this kinds of higher level languages.

play10:12

Higher level languages are more compact because

play10:16

you don't have to write too many things

play10:18

as compared to the assembly languages.

play10:22

And it is easier to understand and debug.

play10:25

So, if you are writing your program in higher level languages,

play10:28

it will be easier to understand.

play10:30

Even if an another person is reading the codes that is written by you

play10:34

we know that it is not very hard to understand if it is written in

play10:38

C, C++ or something like that.

play10:40

And if there are some kind of errors, it will be easy to debug,

play10:44

if this is written in these kinds of high level languages.

play10:47

And then it says it is easier to port.

play10:50

And by easier to port we mean that

play10:52

it wll be easier to port the operating system from one hardware to another.

play10:59

Now, the problems or disadvantages of writing in assembly languages is that

play11:02

if you have written an operating system in assembly language,

play11:06

then that operating system will be supported only in those hardware

play11:11

which are fitted with the processor or the CPU families

play11:15

similar to the one in which you have written your operating system.

play11:18

Like for example -

play11:19

The Microsoft DOS(MS-DOS), stands for Microsoft Disc operating system

play11:24

which is an old operating system.

play11:26

It was written in Intel 8088 assembly language.

play11:30

And because of this, it is available only on the Intel family of CPUs.

play11:35

So, since MS-DOS was written in the Intel 8088 assembly language

play11:40

it is supported only on the Intel family of CPUs.

play11:45

So, the CPUs from the Intel family's are the only one that supports the MS-DOS.

play11:52

But, the Linux operating system in contrast is mostly written in C

play11:56

and is available on number of different CPUs including Intel, Motorola,

play12:01

Spark, MIPS and so on.

play12:03

So, Linux operating system as written in C, which is a higher level language

play12:10

It is available on variety of CPUs.

play12:12

So, this is the advantage.

play12:14

So, that is the example of portability.

play12:17

It is easy to port if you are writing in higher level languages.

play12:20

Alright!

play12:21

So, that was about the implementation of your operating system.

play12:25

So, we discussed about designing, policy, mechanism,

play12:28

and implementation of operating system.

play12:31

So, when we talk about designing of the operating system.

play12:34

It is a vast task

play12:35

and it is not something that can be achieved

play12:37

by following some set of rules

play12:39

or there is no particular text book that will tell you how to do it

play12:42

in order to specify all the design goals and to achieve all of them.

play12:46

So, depending on the kind of requirements and the kind the system

play12:49

that you are developing,

play12:51

you will need to use your creativity in order to design it in the best possible way.

play12:55

So, I hope that was clear to you.

play12:57

That was about the designing and implementation of the operating system.

play13:02

So, Thank you for watching and see you in the next one.

Rate This

5.0 / 5 (0 votes)

الوسوم ذات الصلة
OS DesignImplementationSoftware EngineeringSystem GoalsUser GoalsMechanismPolicyResource AllocationHigher-Level LanguagesAssembly LanguagePortability
هل تحتاج إلى تلخيص باللغة الإنجليزية؟