探索计算机科学底层架构：从零开始的系统理解之旅

需积分: 9 92 浏览量更新于2024-07-19 收藏 1.22MB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

"《计算机科学从底层向上》(ComputerSciencefromtheBottomUp)是一本由Ian Wien撰写的免费在线教材，旨在从基础开始教授计算机科学。作者以其独特的“从底部向上”（bottom-up）方法，将复杂的理论知识分解，以便初学者更好地理解。该书的主要内容包括二进制与逻辑、操作系统内部机制、工具链基础和系统库基础。书中首先介绍通用的Unix系统和高级C语言编程。作者强调一切皆为文件这一概念，通过实例展示如何实现抽象，以及如何使用C语言来实现抽象功能。章节中还涵盖了图书馆（libraries）的概念，解释了文件描述符（file descriptors）的作用，这些都是操作系统底层工作的重要组成部分。随后，读者会深入探讨二进制和二进制逻辑，这对于理解计算机如何处理数据和指令至关重要。在讨论操作系统内部时，作者会揭示现代操作系统的复杂性，如Linux内核（代码量庞大），以及编译器、汇编器和系统库等关键组件。虽然这样的学习过程可能需要一定的前置知识，如大学层次的系统课程、C语言经验，甚至参考手册，但通过逐步学习和实践，学生可以逐渐建立起对操作系统和底层工作的认识。此外，书中还涉及到shell编程，这是用户与操作系统交互的基本方式，了解其工作原理有助于理解和掌握计算机系统的核心逻辑。《计算机科学从底层向上》提供了一个PDF版本，并可在网站<http://www.bottomupcs.com/csbu.pdf>获取，原始源码可通过<https://github.com/ianw/bottomupcs>访问。该作品受到Creative Commons Attribution-ShareAlike许可证保护，鼓励知识共享。作者保留版权，但允许他人在指定条件下自由复制和分发。通过阅读这本书，学习者可以逐步构建起计算机科学的坚实基础，从底层开始，逐步攀登到更高级的技术领域。"

资源详情

资源推荐

General Unix and Advanced C

these programs do not need to worry about the exact details of the JPEG file format, but can concentrate

their efforts on what their program wants to do with the image.

The standard library of a UNIX platform is generically referred to as libc. It provides the basic interface

to the system: fundamental calls such as read(), write() and printf(). This API is described in

its entirety by a specification called POSIX. It is freely available online and describes the many calls that

make up the standard UNIX API.

Most UNIX platforms broadly follow the POSIX standard, though often differ small but sometimes

important ways (hence the complexity of the various GNU autotools, which often tries to abstract away

these differences for you). Linux has many interfaces that are not specified by POSIX; writing applications

that use them exclusively will make your application less portable.

Libraries are a fundamental abstraction with many details. Later chapters will describe how libraries work

in much greater detail.

File Descriptors

One of the first things a UNIX programmer learns is that every running program starts with three files

already opened:

Table 1.1. Standard Files Provided by Unix

Descriptive Name File Number Description

Standard In 0 Input from the keyboard

Standard Out 1 Output to the console

Standard Error 2 Error output to the console

General Unix and Advanced C

Figure 1.3. Abstraction

device_read()

device_write()

device_read()

device_write()

device_read()

device_write()

Device Drivers

MAX_FD

Device Layer

/dev/input

/dev/tty

/dev/sr0

Opening the file

associates a descriptor

with the associated device

int fd = open("/dev/sr0");

with the kernel

which gives them a file

Devices register

int ret = read(fd, &input, count);

File Descriptors

Fur t h er r ef er en ce s

to the descriptor

are routed to the device

File descriptors are an index into a file-descriptor table stored by the kernel. The kernel creates a file-

descriptor in response to an open call and associates the file-descriptor with some abstraction of an

underlying file-like object; be that an actual hardware device, or a file-system or something else entirely.

Consequently a processes read or write calls that reference that file-descriptor are routed to the correct

place by the kernel to ultimately do something useful.

In short, the file-descriptor is the gateway into the kernel's abstractions of underlying hardware. An overall

view of the abstraction for physical-devices is shown in Figure 1.3, “Abstraction”.

Starting at the lowest level, the operating system requires a programmer to create a device-driver to be able

to communicate with a hardware device. This device-driver is written to an API provided by the kernel

just like in Example 1.2, “Abstraction in include/linux/virtio.h”; the device-driver will provide

a range of functions which are called by the kernel in response to various requirements. In the simplified

example above, we can see the drivers provide a read and write function that will be called in response

to the analogous operations on the file-descriptor. The device-driver knows how to convert these generic

requests into specific requests or commands for a particular device.

To provide the abstraction to user-space, the kernel provides a file-interface via what is generically termed

a device layer. Physical devices on the host are represented by a file in a special file-system such as /dev.

In UNIX-like systems, so called device-nodes have what are termed a major and a minor number which

allows the kernel to associate particular nodes with their underlying driver. These can be identified via ls

as illustrated in Example 1.3, “Example of major and minor numbers”.

Example 1.3. Example of major and minor numbers

$ ls -l /dev/null /dev/zero /dev/tty

crw-rw-rw- 1 root root 1, 3 Aug 26 13:12 /dev/null

General Unix and Advanced C

crw-rw-rw- 1 root root 5, 0 Sep 2 15:06 /dev/tty

crw-rw-rw- 1 root root 1, 5 Aug 26 13:12 /dev/zero

This brings us to the file-descriptor, which is the handle user-space uses to talk to the underlying device.

In a broad-sense, what happens when a file is opened is that the kernel is using the path information to

map the file-descriptor with something that provides an appropriate read and write, etc. API. When

this open is for a device (/dev/sr0 above), the major and minor number of the opened device-node

provides the information the kernel needs to find the correct device-driver and complete the mapping. The

kernel will then know how to route further calls such as read to the underlying functions provided by

the device-driver.

A non-device file operates similarly, although there are more layers in-between. The abstraction here is

the mount-point; mounting a file-system has the dual purpose of setting up a mapping so the file-system

knows the underlying device that provides the storage and the kernel knows that files opened under that

mount-point should be directed to the file-system driver. Like device-drivers, file-systems are written to

a particular generic file-system API provided by the kernel.

There are indeed many other layers that complicate the picture in real-life. For example, the kernel will go

to great efforts to cache as much data from disks as possible in otherwise free-memory; this provides many

speed advantages. It will also try to organise device access in the most efficient ways possible; for example

trying to order disk-access to ensure data stored physically close to each other is retrieved together, even if

the requests did not arrive in such an order. Further, many devices are of a more generic class such as USB

or SCSI devices which provide their own abstraction layers to write too. Thus rather than writing directly

to devices, file-systems will go through these many layers. Understanding the kernel is to understand how

these many APIs interrelate and coexist.

The Shell

The shell is the gateway to interacting with the operating system. Be it bash, zsh, csh or any of the

many other shells, they all fundamentally have only one major task — to allow you to execute programs

(you will begin to understand how the shell actually does this when we talk about some of the internals

of the operating system later).

But shells do much more than allow you to simply execute a program. They have powerful abilities to

redirect files, allow you to execute multiple programs simultaneously and script complete programs. These

all come back to the everything is a file idiom.

Redirection

Often we do not want the standard file descriptors mentioned in the section called “File Descriptors” to

point to their default places. For example, you may wish to capture all the output of a program into a file

on disk, or, alternatively have it read its commands from a file you prepared earlier. Another useful task

might like to pass the output of one program to the input of another. With the operating system, the shell

facilitates all this and more.

Table 1.2. Standard Shell Redirection Facilities

Name Command Description Example

Redirect to a file > filename Take all output from

standard out and place

it into filename. Note

using >> will append

to the file, rather than

overwrite it.

ls > filename

General Unix and Advanced C

Name Command Description Example

Read from a file < filename Copy all data from the

file to the standard input

of the program

echo < filename

Pipe program1 |

program2

Take everything from

standard out of

program1 and pass it

to standard input of

program2

ls | more

Implementing pipe

The implementation of ls | more is just another example of the power of abstraction. What

fundamentally happens here is that instead of associating the file-descriptor for the standard-output with

some sort of underlying device (such as the console, for output to the terminal), the descriptor is pointed

to an in-memory buffer provided by the kernel commonly termed a pipe. The trick here is that another

process can associate its standard input with the other-side of this same buffer and effectively consume

the output of the other process. This is illustrated in Figure 1.4, “A pipe in action”

Figure 1.4. A pipe in action

Buffer

File Descriptors

MAX_FD

File Descriptors

MAX_FD

$ ls | more

write()

read()

Kernel

User

pipe

ls more

The pipe is an in-memory buffer that connects two processes together. File-descriptors point to the pipe

object, which buffers data sent to it (via a write) to be drained (via a read)

Writes to the pipe are stored by the kernel until a corresponding read from the other side drains the buffer.

This is a very powerful concept and is one of the fundamental forms of inter-process communication

or IPC in UNIX like operating systems. The pipe allows more than just a data transfer; it can act as a

signaling channel. If a process reads an empty pipe, it will by default block or be put into hibernation

until there is some data available (this is discussed in much greater depth in Chapter 5, The Process. Thus

two processes may use a pipe to communicate that some action has been taken just by writing a byte of

data; rather than the actual data being important, the mere presence of any data in the pipe can signal a

message. Say for example one process requests that another print a file - something that will take some

time. The two processes may setup a pipe between themselves where the requesting process does a read

on the empty pipe; being empty that call blocks and the process does not continue. Once the print is done,

the other process can write a message into the pipe, which effectively wakes up the requesting process

and signals the work is done.

剩余192页未读，继续阅读

weixin_30580135

粉丝: 0
资源: 2

探索计算机科学底层架构：从零开始的系统理解之旅

BS和CS架构

Cs架构例程解析 .rar

bs架构与cs架构的区别

bs架构和cs架构区别

BS架构与CS架构有何区别？

bs架构 和cs架构 区别

CS架构和BS架构的区别

bs和cs架构 通讯协议

用c#怎么开发出一个cs架构应用

cs架构和bs架构哪个好

什么还是cs架构，什么是bs架构

bs架构与cs架构的优缺点

bs架构与cs架构的区别(面试必备)

在线聊天的小程序是bs架构还是cs架构

qt程序实现cs架构

BS架构与CS架构有什么区别

微内核结构中怎样使用cs架构

cs架构软件概要设计说明书

python中paramiko插件

fastcache-1.1.0-cp38-cp38-win_amd64.whl

最新资源

bs架构和cs架构区别

bs和cs架构通讯协议