Lecture 2 Page 1 CS 111 Online Operating System Basics CS 111 On-Line MS Program Operating Systems Peter Reiher.

Lecture 2Page 1CS 111 Online

Operating System BasicsCS 111

On-Line MS ProgramOperating Systems

Peter Reiher


Outline

• Important properties for an operating system• Critical abstractions for operating systems• System services


Important OS Properties

• For real operating systems built and used by real people

• Differs depending on who you are talking about– Users– Service providers– Application developers– OS developers


For the End Users,

• Reliability • Performance• Upwards compatibility in releases• Support for differing hardware– Currently available platforms–What’s available in the future

• Availability of key applications• Security


Reliability

• Your OS really should never crash– Since it takes everything else down with it

• But also need dependability in a different sense– The OS must be depended on to behave as it’s

specified– Nobody wants surprises from their operating

system– Since the OS controls everything, unexpected

behavior could be arbitrarily bad


Performance

• A loose goal• The OS must perform well in critical situations• But optimizing the performance of all OS

operations not always critical• Nothing can take too long• But if something is “fast enough,” adding

complexity to make it faster not worthwhile


Upward Compatibility

• People want new releases of an OS– New features, bug fixes, enhancements

• People also fear new releases of an OS– OS changes can break old applications

• What makes the compatibility issue manageable?– Stable interfaces


Stable Interfaces

• Designers should start with well specified Application Interfaces–Must keep them stable from release to release

• Application developers should only use committed interfaces– Don’t use undocumented features or erroneous

side effects


Interfaces and Standards

• Standards in the Dark Ages (1965)• The S/W Reformation (1985)• The role of standards today• APIs• ABIs


Standards in the Dark Ages (1965)

• No software industry as we now know it• All the money was made on hardware– But hardware is useless without software– All software built by hardware suppliers– Platforms were distinguished by software

• Software portability was an anti-goal– Keep customers captive to your hardware– Portability means they could go elsewhere

• Standards were few and weak


The S/W Reformation (1985)• An outgrowth of the popular commodity PC• The advent of the “killer application”– Desk-top publishing, spreadsheets, ...– The rise of the Independent Software Vendor

• Fundamental changes to platform industry– The “applications, demand, volume” cycle– Application capture became strategic

• Applications portability also became strategic– Standards are the key to portability– Standards compliance became strategic


Standards Today

• There are many software standards– Subroutines, protocols and data formats, …– Both portability and interoperability– Some are general (e.g. POSIX 1003, TCP/IP)– Some are very domain specific (e.g. MPEG2)

• Key standards are widely required– Non-compliance reduces application capture– Non-compliance raises price to customers– Proprietary extensions are usually ignored


APIs• Application Program Interfaces – A source level interface, specifying• Include files, data types, constants• Macros, routines and their parameters

• A basis for software portability– Recompile program for the desired architecture– Linkage edit with OS-specific libraries– Resulting binary runs on that architecture and OS

• An API compliant program will compile & run on any compliant system


ABIs• Application Binary Interfaces – A binary interface, specifying• Dynamically loadable libraries (DLLs)• Data formats, calling sequences, linkage conventions

– The binding of an API to a hardware architecture

• A basis for binary compatibility– One binary serves all customers for that hardware• E.g. all x86 Linux/BSD/MacOS/Solaris/…• May even run on Windows platforms

• An ABI compliant program will run (unmodified) on any compliant system


For the Service Providers,• Reliability • Performance• Upwards compatibility in releases • Platform support (wide range of platforms)• Manageability• Total cost of ownership • Support (updates and bug fixes) • Flexibility (in configurations and applications)• Security


For the Application Developers,• Reliability • Performance• Upwards compatibility in releases• Standards conformance• Functionality (current and roadmap)• Middleware and tools• Documentation• Support (how to ...)


For the OS Developers,

• Reliability• Performance • Maintainability• Low cost of development– Original and ongoing


Maintainability

• Operating systems have very long lives– Solaris, the “new kid on the block,” came out in 1993

• Basic requirements will change many times• Support costs will dwarf initial development• This makes maintainability critical• Aspects of maintainability:

– Understandability– Modularity/modifiability – Testability


Maintainability: Understandability

• Code must be learnable by mortals– It will not be maintained by the original developers– New people must be able to come up to speed

• Code must be well organized– Nobody can understand 1M lines of random code– It must have understandable, hierarchical structure

• Documentation– High level structure, and organizing principles– Functionality, design, and rationale for modules– How to solve common problems

Modern operating systems are often

millions of lines long. Can anyone understand them entirely, even if

well-organized? If not, what does that imply?


Why a Hierarachical Structure?• Not absolutely necessary, but . . .• Hierarchical layers can usually be understood

without having to completely understand the implementation

• Expansion of one sub-system in a hierarchy can usually be understood without having to understand the expansion of other sub-systems

• Other structures tend not to have those advantages


Maintainability: Modularity and Modifiability

• Modules must be understandable in isolation– Modules should perform coherent functions– Well-specified interfaces for each module– Implementation details hidden within module– Inter-module dependencies should be few/simple/clean

• Modules must be independently changeable– Lots of side effects mean lots of bugs– Changes to one module should not affect others

• Keep It Simple Stupid– Costs of complexity usually outweigh the rewards


Side Effects

• A side effect is a situation where an action in one object has non-obvious consequences – Perhaps even to other objects

• Side effects often happen when state is shared between seemingly independent modules and functions

• Side effects lead to unexpected behaviors• And the resulting bugs can be hard to find

Are side effects always undesirable?


Maintainability: Testability• OS must work, so its developers must test it• Thorough testing is key to reliability– All modules must be thoroughly testable– Most modules should be testable in isolation

• Testability must be designed in from the start– Observability of internal state– Triggerability of all operations and situations– Isolability of functionality

• Testing must be automated– Functionality, regression, performance, – Stress testing, error handling handling


Automated Testing

• Why is it important that testing be automated?

• Automated tests can be run often (e.g. after every change) with very little cost or effort

• Automatically executed tests are much more likely to be run completely and correctly every time

• And discrepancies are much more likely to be noted and reported

What factors make it complicated to perform

automated testing?


Cost of Development

• Another area where simplicity wins• If it’s simple, it will be quicker and cheaper to

build• Even better, there will be fewer bugs– And thus less cost for bug fixes

• And changing/extending it will be cheaper

Lecture 2 Page 1 CS 111 Online Operating System Basics CS 111 On-Line MS Program Operating Systems Peter Reiher.

Documents

online standards

standards standards

online interfaces

strategic slide

online performance

os os changes

basics cs

online reliability