No.1) 英語はmust!! 今日読んだ英語のscripts!!
/*
4.2 BIOS device mapping techniques
Both of these techniques should be usable from any PC operating system, and neither require any special support in the drivers themselves. This section will be flushed out into detailed explanations, particularly for the I/O restriction technique.
The general rule is that the data comparison technique is the quick and dirty solution. It works most of the time, but doesn't cover all the bases, and is relatively simple.
The I/O restriction technique is much more complex, but it has potential to solve the problem under all conditions, plus allow access of the remaining bios devices when not all of them have operating system drivers.
/*
4.2.2 I/O restriction technique
This first step may be unnecessary, but first create copy-on-write mappings for the device drivers writing into pc ram. Keep the original copies for the clean bios virtual machine to be created later.
For each device driver brought online, determine which bios devices become inaccessible by:
- Create a clean bios virtual machine.
- Set the I/O permission map for the I/O area claimed by the device driver to no permissions (neither read nor write).
- Access each device.
- Record which devices succeed, and those which try to access the restricted I/O areas (hopefully, this will be an xor situation).
For each device driver, given how many of the bios devices were subsumed by it (there should be no gaps in this list), it should be easy to determine which devices on the controller these are.
In general, you have at most 2 disks from each controller given bios numbers, but they pretty much always count from the lowest logically numbered devices on the controller.
/*
4.3 Example OS code
In this distribution, the example Multiboot kernel kernel is included. The kernel just prints out the Multiboot information structure on the screen, so you can make use of the kernel to test a Multiboot-compliant boot loader and for reference to how to implement a Multiboot kernel. The source files can be found under the directory doc in the Multiboot source distribution.
The kernel kernel consists of only three files: boot.S, kernel.c and multiboot.h. The assembly source boot.S is written in GAS (see GNU assembler), and contains the Multiboot information structure to comply with the specification. When a Multiboot-compliant boot loader loads and execute it, it initialize the stack pointer and EFLAGS, and then call the function cmain defined in kernel.c. If cmain returns to the callee, then it shows a message to inform the user of the halt state and stops forever until you push the reset key. The file kernel.c contains the function cmain, which checks if the magic number passed by the boot loader is valid and so on, and some functions to print messages on the screen. The file multiboot.h defines some macros, such as the magic number for the Multiboot header, the Multiboot header structure and the Multiboot information structure.
kayo .～＊
