|
|
|
Modern Operating Systems by Herbert Bos and Andrew S. Tanenb...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf
Showing 1024 out of 1137
Modern Operating Systems by Herbert Bos and Andrew...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Modern Operating Systems by Herbert...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Page 1024
SEC. 12.2
INTERFACE DESIGN
993
On the other hand, some remote file-access protocols are connectionless. The
Web protocol (HTTP) is connectionless.
To read a Web page you just ask for it;
there is no advance setup required (a TCP connection
is
required, but this is at a
lower level of protocol. HTTP itself is connectionless).
The trade-off
between any
connection-oriented mechanism and a con-
nectionless one is the additional work required to set up the mechanism (e.g., open
the file), and the gain from not having to do it on (possibly many) subsequent calls.
For file I/O on a single machine, where the setup cost is low, probably the standard
way (first open, then use) is the best way. For remote file systems, a case can be
made both ways.
Another issue relating to the system-call interface is its visibility. The list of
POSIX-mandated system calls is easy to find. All UNIX systems support these, as
well as a small number of other calls, but the complete list is always public.
In
contrast, Microsoft has never made the list of Windows system calls public. Instead
the WinAPI and other APIs have been made public, but these contain vast numbers
of library calls (over 10,000) but only a small number are true system calls. The
argument for making all the system calls public is that it lets programmers know
what is cheap (functions performed in user space) and what is expensive (kernel
calls). The argument for not making them public is that it gives the implementers
the flexibility of changing the actual underlying system calls to make them better
without breaking user programs. As we saw in Sec. 9.7.7, the original designers
simply got it wrong with the
access
system call, but now we are stuck with it.
12.3 IMPLEMENTATION
Turning away from the user and system-call interfaces, let us now look at how
to implement an operating system.
In the following sections we will examine
some general conceptual issues relating to implementation strategies. After that we
will look at some low-level techniques that are often helpful.
12.3.1 System Structure
Probably the first decision the implementers have to make is what the system
structure should be.
We examined the main possibilities in Sec. 1.7, but will
review them here.
An unstructured monolithic design is not a good idea, except
maybe for a tiny operating system in, say, a toaster, but even there it is arguable.
Layered Systems
A reasonable approach that has been well established over the years is a lay-
ered system. Dijkstra’s THE system (Fig. 1-25) was the first layered operating sys-
tem. UNIX and Windows 8 also have a layered structure, but the layering in both
Ace your assessments! Get Better Grades
Browse thousands of Study Materials & Solutions from your Favorite Schools
Concordia University
Concordia_University
School:
Operating_Systems
Course:
Introducing Study Plan
Using AI Tools to Help you understand and remember your course concepts better and faster than any other resource.
Find the best videos to learn every concept in that course from Youtube and Tiktok without searching.
Save All Relavent Videos & Materials and access anytime and anywhere
Prepare Smart and Guarantee better grades
Students also viewed documents
lab 18.docx
lab_18.docx
Course
Course
3
Module5QuizSTA2023.d...
Module5QuizSTA2023.docx.docx
Course
Course
10
Week 7 Test Math302....
Week_7_Test_Math302.docx.docx
Course
Course
30
Chapter 1 Assigment ...
Chapter_1_Assigment_Questions.docx.docx
Course
Course
5
Week 4 tests.docx.do...
Week_4_tests.docx.docx
Course
Course
23
Week 6 tests.docx.do...
Week_6_tests.docx.docx
Course
Course
106