OS-VOS.rar_OS-V_Simics_linuxvos_voslinux_vosforlinux资源-CSDN下载

共290个文件

o：106个

c：97个

h：52个

版权申诉

3 浏览量 2022-09-21 03:55:34 上传评论收藏 839KB RAR 举报

《OS-VOS在Linux环境下的实现与探索》在当今的计算机科学领域，操作系统（Operating System，简称OS）的研究和开发是一项至关重要的工作。而VOS（Virtual Operating System）是一种模拟操作系统，它允许用户在无需实际硬件的情况下进行操作系统的学习和测试。本教程将围绕“OS-VOS.rar”这个压缩包，探讨如何在Linux环境下搭建和运行VOS，以及如何通过“OS-lab1”这样的实验来深入理解VOS的工作原理。我们需要了解OS-VS和Simics的关系。Simics是一款强大的全系统模拟器，它能够模拟各种处理器架构以及完整的计算机系统，包括内存、I/O设备等。在Linux环境下，Simics是实现OS-VOS的关键工具，它为VOS提供了一个运行的平台，使得开发者可以在不依赖真实硬件的情况下进行VOS的实验和调试。在“OS-VOS.rar”压缩包中，包含了用于在Linux上运行VOS所需的所有文件。"www.pudn.com.txt"可能是一个文档，里面可能包含了获取和安装Simics的步骤，以及如何配置VOS在Simics中的运行环境。而"OS-lab1"很可能是VOS的第一个实验项目，它会引导用户逐步了解VOS的基本操作和功能。在Linux环境下搭建VOS，首先需要安装Simics。这通常涉及到下载Simics软件包，解压，然后按照提供的文档进行编译和安装。安装完成后，需要根据"www.pudn.com.txt"的指导，设置Simics以模拟VOS运行的环境。这可能包括配置处理器类型、内存大小、I/O设备等参数。接下来，我们将焦点转向"OS-lab1"。这个实验可能涵盖了VOS的基本操作，例如启动、停止、进程管理、内存分配等。通过这些实验，用户可以亲身体验到操作系统的基本运作机制，理解进程调度、内存管理等核心概念。实验通常会包含一系列的步骤，每个步骤都有明确的目标和预期结果，帮助学习者逐步深入理解VOS的内部工作流程。在进行实验时，用户可能会遇到各种问题，如模拟器配置错误、VOS运行异常等。解决这些问题的过程也是学习的一部分，通过调试和查阅相关资料，用户可以进一步提高对操作系统原理的理解。 "OS-VOS.rar"提供了一个在Linux环境下学习和实践VOS的完整框架。借助Simics的强大模拟能力，即使没有真实的硬件，也能实现VOS的运行和实验。通过"OS-lab1"这样的实践，不仅可以掌握VOS的操作，还能深入理解操作系统的核心概念，对于提升开发者的技术能力和理论素养具有显著的作用。在实际操作中，应仔细阅读相关文档，耐心地进行每一个步骤，以确保获得最佳的学习效果。

资源详情

资源评论

资源推荐

收起资源包目录

OS-VOS.rar_OS-V_Simics_linux vos_vos linux_vos for linux （290个子文件）

_test 99KB

libx86.a 105KB

liblmm.a 87KB

libstring.a 52KB

libstdio.a 26KB

libstdlib.a 15KB

libdebug.a 2KB

doprnt.c 13KB

keyhelp.c 9KB

kernel.c 6KB

pic.c 5KB

doscan.c 4KB

lmm_alloc_gen.c 4KB

base_multiboot_init_cmdline.c 4KB

console.c 4KB

seg.c 4KB

sprintf.c 4KB

base_gdt_init.c 4KB

base_multiboot_init_mem.c 3KB

printf.c 3KB

lmm.malloc.c 3KB

lmm_free.c 3KB

base_gdt_load.c 3KB

kernel_init.c 3KB

strsep.c 3KB

strtok_r.c 3KB

strtok.c 3KB

strcasecmp.c 3KB

strcspn.c 2KB

strncat.c 2KB

getenv.c 2KB

sscanf.c 2KB

memchr.c 2KB

lmm_add_free.c 2KB

base_trap.c 2KB

strspn.c 2KB

phys_lmm_init.c 2KB

strpbrk.c 2KB

trap_dump.c 2KB

lmm_add_region.c 2KB

lmm_alloc.c 2KB

base_multiboot_main.c 2KB

base_irq.c 2KB

lmm_find_free.c 2KB

mallocf.c 2KB

lmm_dump.c 2KB

mytest.c 2KB

phys_lmm_add.c 2KB

memcmp.c 2KB

malloc.c 2KB

lmm_stats.c 2KB

strcmp.c 2KB

_test.c 2KB

strncpy.c 2KB

base_irq_init.c 2KB

strtol.c 2KB

proc_reg.c 2KB

strtoul.c 2KB

base_cpu_init.c 2KB

smallocf.c 2KB

lmm_remove_free.c 2KB

strcpy.c 1KB

strlen.c 1KB

smalloc.c 1KB

ctype.c 1KB

panic.c 1KB

base_gdt.c 1KB

puts.c 1KB

gate_init.c 1KB

base_idt_load.c 1KB

lmm_avail.c 1KB

strcat.c 1KB

base_tss_init.c 1KB

base_irq_default_handler.c 1KB

strstr.c 1KB

base_trap_ignore_handler.c 1KB

base_tss_load.c 1KB

lmm_alloc_page.c 1KB

putchar.c 1KB

lmm_alloc_aligned.c 1KB

base_trap_default_handler.c 1KB

strncmp.c 1KB

base_irq_softint_handler.c 1KB

base_cpu_load.c 1KB

base_trap_init.c 1KB

trap_dump_panic.c 1KB

strrchr.c 1KB

rindex.c 1KB

base_irq_softint.c 1KB

base_fpu_init.c 1KB

strdup.c 1KB

strchr.c 1KB

lmm_free_page.c 1KB

bcmp.c 1KB

lmm_avail_in.c 1KB

atol.c 1KB

lmm_init.c 1KB

linear_base_va.c 1KB

base_idt.c 1KB

phys_mem_max.c 1023B

共 290 条

OS2006 Lab#1 Documentation TA: Tao Jie (052053007@fudan.edu.cn)

第 1 页共 19 页

Lab＃1 Documentation

Part I: Lab Overview ...............................................................2

1, Goals.....................................................................................................................................2

2, Technology Disclaimer........................................................................................................3

3, Welcome to x86 Kernel Programming ..............................................................................3

3.1 Kernel Programming: Always Assuming the Worst ..............................................3

3.2 Privilege Levels..........................................................................................................4

3.3 Segmentation .............................................................................................................4

3.4 Communicating with Devices...................................................................................5

3.5 Hardware Interrupts.................................................................................................5

3.6 Software Interrupts and Exceptions........................................................................6

3.7 Writing an Interrupt Handler..................................................................................8

4, Console Device Driver Specification..................................................................................9

4.1 Writing a Character to the Console.........................................................................9

4.2 Communicating with the CRTC ..............................................................................9

4.3 Console Device Driver Interface............................................................................10

5, Timer Device Driver Specification...................................................................................11

5.1 Configuring the Timer............................................................................................11

5.2 Timer Device Driver Interface...............................................................................12

6, Keyboard Device Driver Specification............................................................................12

6.1 Interacting with the Keyboard...............................................................................12

6.2 Keyboard Device Driver Interface.........................................................................13

7, Skeleton Kernel (VOS, mytest, _test choices in GRUB) ................................................13

8, Provided C Functions .......................................................................................................13

9, Testing ................................................................................................................................14

10, Other Important Notes ...................................................................................................14

11, Testing and Debugging with Simics ...............................................................................14

12, A Note on "Triple Faults"...............................................................................................15

Part II: Lab Specification ......................................................16

1, About Quadruple Images .................................................................................................16

2, Devices Driver ...................................................................................................................16

3, Simple VOS Game.............................................................................................................16

4, Simics Debugging Exercise...............................................................................................17

4.1 Job 1 – Register accessing.......................................................................................18

4.2 Job 2 – Virtual memory..........................................................................................18

4.3 Job3 - Symbolic Debugging....................................................................................18

5, How to submit your work?...............................................................................................18

6, The gap between Part1 and Part2 ...................................................................................19

Contact with the TA-in-charge of Lab#1..............................19

OS2006 Lab#1 Documentation TA: Tao Jie (052053007@fudan.edu.cn)

第 2 页共 19 页

Part I: Lab Overview

In this introductory Lab you will be writing three device drivers.

The first is the console device driver. The console device driver is responsible for taking

characters and printing them on the screen. Without it, it would be rather difficult to obtain any

feedback as to what is going on in your operating system or user applications.

The second device driver you will write is the keyboard device driver. Whenever the user

presses a key, the keyboard device driver needs to find out what key it is, whether it was pushed or

released, and then make that information available to the operating system. An important aspect of

the keyboard device driver is that it is interrupt driven. We will take a closer look at what this

means later.

The third "device driver" is the timer handler. While we do not often think of the on board PC

timer as a device, it generates interrupts just like the keyboard. The timer is a critical device that is

used in context switching between processes.

It is not possible to test these device drivers on their own. In order to develop and test them,

you will be provided with a skeleton kernel. The kernel performs some very basic machine

initialization such as transiting to protected mode. Once this initialization is complete, it transfers

control to the main() function, which is where you can put your initialization and test routines.

There is no virtual memory and no file system.

Once you have implemented the three device drivers, you will use the three of them to

implement a wonderful PC game, VOS, reminiscent of the most popular music game in Y2K. A

detailed explanation of the desired behavior is presented later in this handout.

1, Goals

Despite the fact that this is the smallest labs of all the OS labs that will be assigned in this

class, it is important to pay attention to the key concepts in Lab 1. The ideas taught here will

provide the foundation for the next three labs. In particular, we would like you to be comfortable

with:

1. Writing clean code in C. Many people like the C programming language because it gives the

programmer a lot of freedom (pointers, casting, etc). It is very easy to hang yourself with this

rope. Developing (and sticking with) a consistent system of variable definitions, commenting,

and separation of functionality is essential.

People have asked about using C++ in this class. This is probably much harder than you think,

since you would need to begin by implementing your own thread-safe (or, at least,

interrupt-aware) versions of new and delete. In addition, you would probably find yourself

implementing other pieces of C++ runtime code; this could turn into quite a hobby. As a

result, we cannot help you with C++ and will not be able to provide you with extra time to

complete the assignments.

If you really would like to use an alternative language, you may do so, but at your own risk.

We will not answer any questions regarding other languages or integrating the support code

with another language. If you use another language and do not complete the Lab, you will not

be given any sympathy because you used something other than C.

2. Writing pseudo-code. For systems programming, it is very important to think out crucial data

OS2006 Lab#1 Documentation TA: Tao Jie (052053007@fudan.edu.cn)

第 3 页共 19 页

structures and algorithms ahead of time since they become important primitives for the rest of

the system.

3. Debugging/testing operating system code. We will be using Simics, an instruction set

simulator with a built-in debugger to debug and test; it is similar to gdb, but has some

important differences and will take some getting used to.

4. Using common development tools (gcc, ld, objdump, simics…).

5. Understanding device drivers: their role in the system, and their requirements.

6. Communicating with the TAs using various channels of communication (Q&A archive, BBS,

email, etc.).

In addition to these primary goals, mundane details such as software installation should be

taken care of by the end of Lab 1.

2, Technology Disclaimer

Because of the availability, low cost, and widespread use of the x86 architecture, it was

chosen as the platform for this sequence of labs. As its creator, Intel Corporation has provided

much of the documentation used in the development of these labs. In its literature, Intel uses and

defines terms like interrupt, fault, etc. On top of this the x86 architecture will be the only platform

used in these labs.

The goal of this Lab set is certainly not to teach the idiosyncrasies of the x86 architecture (or

Intel's documentation). That said, it will be necessary to become accustomed to the x86 way of

doing things, and the Intel nomenclature, for the purposes of completing this Lab set. Just keep in

mind that the x86 way of doing things is not the only way of doing things. It is the price to be paid

for learning the principles of operating systems on a real world system instead of a simulated

architecture.

3, Welcome to x86 Kernel Programming

These labs will be a new experience for many of you because they are special in two ways.

The first is that, as kernel programmers, you are subject to a number of constraints that do not

show up in user-level programming. The second is that you will need to look down at the

hardware you are running on and manipulate device registers/processor data structures to get your

kernel to work. Because this is new for many of you, the following section is devoted to saying a

few things about kernel programming, and then summarizing some of the important features of the

x86 architecture which you will need to know.

3.1 Kernel Programming: Always Assuming the Worst

Programming in the kernel is quite different from writing user level applications. As has been

emphasized in class, safety is a priority in kernel code - that is, checking pointers passed to you by

user code before you dereference them, testing all possible cases to ensure there are no infinite

loops, etc. Kernels need to be as absolutely bulletproof as possible. For example, the following

line will happily execute as part of your kernel:

*(char*)0x0 = 0x1badd00d;

OS2006 Lab#1 Documentation TA: Tao Jie (052053007@fudan.edu.cn)

第 4 页共 19 页

Wild pointer accesses are much more dangerous in kernel mode because valuable kernel data

structures are not protected by the user mode/kernel mode protection schemes of the processor

(discussed here shortly). Dereferencing and writing to a bad pointer like this within the kernel can

overwrite crucial kernel data.

3.2 Privilege Levels

The x86 architecture uses privilege levels to make defending the kernel against wild user

processes easier. There are four privilege levels ranging from zero to three, with zero being the

most privileged and three being the least. At any given time, the processor is "executing" in one of

these four privilege levels. As you might have already guessed, your kernel code will execute at

privilege level zero, while user code should execute at privilege level three. We will not be using

privilege levels one or two in these labs. We will refer to privilege levels zero and three as PL0

and PL3 respectively. Because of the way privilege levels are explained in section 4.5 of

intel-sys.pdf,

privilege levels are often called "rings" (as in ring zero or ring three), though we will

try to avoid that notation in these labs.

The processor checks the privilege level (PL) in a number of circumstances, such as when an

attempt is made to execute a privileged instruction. These are instructions that modify control

registers or change how the processor is running (a list of these instructions can be found in

section 4.9 of intel-sys.pdf); instructions we would want only the kernel to be able to execute.

3.3 Segmentation

While we will try to avoid using segmentation as much as possible for the duration of these

labs, the x86 architecture requires at least minimal use of segmentation. In order to install

interrupts and manage processes you will need to understand what a segment is. Unlike virtual

memory however, segments are straightforward and will not do much to complicate your life.

A segment is simply a portion of the address space. Once defined, we can associate important

characteristics with the segment, like the priority level required to access the segment or whether it

contains code or data. A segment does not need to represent memory that actually exists - for

example, we could define a segment ranging from 0 to 4GB (the entire 32 bit address space), even

though we might only have 128MB of physical memory.

Because your kernels are going to be complicated enough as it is, we will steer clear of

segmentation by using only four segments. These four segments all span the entire 32 bit address

space (overlapping each other completely). Two of them require privilege level 0 to be accessed,

and two of them only require privilege level 3. Of each privilege level pair, one segment

represents code and the other data. We have set up these segments for you. In this Lab, we have no

user processes, so the only segments that will be used are those requiring PL 0 to be accessed. To

refer to these segments when configuring kernel data structures (like IDT entries), use the #defines

in lib/inc/x86/seg.h (KERNEL_CS_SEGSEL and KERNEL_DS_SEGSEL for this Lab). These

numbers are segment selectors, which are simply indices into another processor data structure, the

global descriptor table (GDT). The GDT is the place we have defined our segments. You do not

have to reconfigure it or know its format, however.

Please refer to our segmentation document

for a more detail explanation of segmentation. Do

OS2006 Lab#1 Documentation TA: Tao Jie (052053007@fudan.edu.cn)

第 5 页共 19 页

not worry if parts of it do not make sense at the moment as they will become clearer later in the

course.

3.4 Communicating with Devices

There are two ways to communicate with a device on the x86 architecture. The first is to send

bytes to an I/O port. The second is through memory-mapped I/O.

Most devices in the x86 architecture are accessed through I/O ports. These ports are

controlled by special system hardware that has access to the data, address, and control lines on the

processor. By using special hardware instructions to read and write from these ports, we can use

I/O ports without infringing upon the normal address space of the kernel or user applications. This

is because these special instructions tell the hardware that this memory reference is actually an I/O

port, not a traditional memory location. For more information on I/O ports, consult chapter 10 of

intel-arch.pdf. Both the timer and the keyboard use I/O ports. For convenience, an assortment of C

wrapper functions are provided to you to save you from having to break into assembly language to

read or write I/O ports. These are located in lib/inc/x86/pio.h. The various in functions read from

an I/O port while the out functions write to an I/O port. The letter after the name indicates the size

of the data being sent (b - byte, w - word/short, l - long/int). You should only need to use outb and

inb.

There are also some devices which are accessed by reading and writing special addresses in

traditional memory (memory-mapped I/O). This part of memory is part of the regular address

space and therefore needs to be carefully managed. The console uses memory-mapped I/O (along

with some I/O ports for things like cursor position).

3.5 Hardware Interrupts

A kernel programmer often uses either I/O ports or memory-mapped I/O to send commands

to devices (ranging in size from single byte commands to many words). How do hardware devices

communicate with kernel? When a packet arrives at a network interface, the user presses a key on

the keyboard or moves the mouse, or any other type of event occurs at a hardware device, that

device needs a way of getting the attention of the kernel. One way is for the kernel to keep asking

the device if it has something new to report (either periodically or continuously). This is called

polled I/O. This is wasteful of CPU time however and there is a better mechanism. That

mechanism is the hardware interrupt.

When a device wants to raise a hardware interrupt, it communicates this desire to one of two

programmable interrupt controllers (PICs) by asserting some control signals on interrupt request

lines. The PICs are responsible for serializing the interrupts (taking possibly concurrent interrupts

and ordering them), and then communicating the interrupts to the processor through special

control lines. The PICs tell the processor that a hardware interrupt has occurred, as well as which

request line the interrupt occurred on so the processor knows how to handle the interrupt. There

are some PC conventions as far as what devices are associated with what interrupt request lines.

PIC 1

0 Timer

PIC 2

8 Real Time Clock

评论收藏

内容反馈

版权申诉

alvarocfc

粉丝: 156

OS-VOS.rar_OS-V_Simics_linux vos_vos linux_vos for linux

评论0

最新资源

OS-VOS.rar_OS-V_Simics_linux vos_vos linux_vos for linux

评论0

simics安装

linux_OS.rar_二级文件系统

OS.rar_linux操作系统_os_os 实验_操作系统 实验_操作系统实验

linux_OS.rar_clubnqr_lntron6_pricefrs

caozuoxitong.rar_linux 课程设计_山大OS课设

vos：一个x86_64架构下的裸机虚拟化系统，不定期更新

Linux各种版本的系统

linux操作系统

simics-user-guide-for-unix.rar_Simics

冰河的渗透实战笔记-冰河.pdf

stm32f103 adc采样+dma传输+fft处理 频率计_fft处理_stm32_ADCFFT_频率计_ADC采样_

ISO21434.pdf

Web安全漏洞扫描工具-AWVS14

J-LINK V10 V11固件.rar

Web中间件常见漏洞总结.pdf

jts-1.14.zip

数据结构与算法分析--C语言描述_数据结构与算法_

cisp-pte渗透测试资源下载 （考试环境+题库）

RK3568硬件设计资料.zip_C#

CobaltStrike4.4.zip

pconline1478255959502.rar

DEAP2.1.zip_DEA2.1软件下载_dea 2.1软件下载_deap2.1_deap2.1基础模型_dea模型

QT帮助文档_中文版_QT中文版帮助文档_

APPinvent，蓝牙软件源文件

goby2021红队专版，1.8.255

内网渗透攻击线路图.pdf

AWD之赛前培训.pptx

海康威视配置文件解码专用工具器.rar

苹果越狱解ID博客中提到的所有工具集.zip

1272+C#+六轴运动控制+实例源码 (1)_C#+六轴运动控制+实例源码_运动控制_运动控制卡_

最新资源

OS.rar_linux操作系统_os_os 实验_操作系统实验_操作系统实验

stm32f103 adc采样+dma传输+fft处理频率计_fft处理_stm32_ADCFFT_频率计_ADC采样_

cisp-pte渗透测试资源下载（考试环境+题库）