Linux : Linux 核心變革，採用新的 CFS 行程排班器
發表人 ols3 於 2007/8/8 12:21:08 (1705 人讀取)
Linux
小三報導:
七月中旬到八月初期間，Linux 核心開發社群裡頭，出現了一點爭論話題。
從 Linux 2.6.23 開始，Linux 核心將把使用多時的 0/1 行程排班器換掉，新採用的 scheduler 稱為完全公平排班器(CFS: Completely Fair Scheduler)，這個排班器是由目前在 RedHat 任職的開發人員 Ingo Molnar 在今年 4 月 11 日開始發展的，CFS 在 62 個小時內就被設計出來。在此之前，Linux 核心開發社群中，早有一群人長期擁護的另一個 SD 排班器，卻始終不被 Linus 接受，CFS 的開發時間最短，但卻能立即出線，這讓 SD 的擁護者十分不能接受，因此對於 CFS vs SD 孰優孰劣的爭論，成為最近核心開發社群中的一個熱門話題。
在 Linus 選擇 CFS 成為新的 Linux 行程排班器之後，長期以來專注於提升 Linux 桌面應用效能的業餘核心開發者 Con Kolivas (本職是墨爾本一家醫院的麻醉師，核心開發是他業餘的興趣)宣佈他將不再維護 SD 行程排班器的 ck- 修補程式碼，並且宣佈退出 Linux 核心的開發行列。ck- patch 最早可追溯到 2002 年 Linux 2.4 系列的核心。不過，多年來 Con Kolivas 的修補程式一直無法被核心主力開發群所接受，因此從未進入 Linux 核心主流程式碼中。Con Kolivas 並發表了一些對 Linux 核心開發群始終不重視桌面應用的言論，他在接受 APCMag 專訪時，詳細地解釋他為何要離開(Why I quit: kernel developer Con Kolivas, http://apcmag.com/6735/interview_con_kolivas)。對於這篇專訪，Linus 在郵件論壇中罕見地帶著生氣的口吻反駁，Linus 表示大部份核心開發人員都是 Linux 桌面的使用者，不但不可能忽視 Linux 核心在桌面應用的效能關注，相反地 Linus 認為 Linux 桌面應用一直是核心開發範圍中最重要的一部份(Torvalds rebukes desktop critics, http://www.techworld.com/opsys/news/index.cfm?newsid=9652)。
CFS vs SD 的爭論在核心郵遞論壇中漫延一陣子之後，Linus 最後出面說明他為什麼捨棄 SD 而選擇 CFS 的緣由(http://kerneltrap.org/node/14008)。
Linus 說道: "那些認為 SD 排班器是完美的人，根本忽略了現實問題，很遺憾地，包括 Con Kolivas 自己都是如此，這也是為什麼長期以來我從不接受 SD 程式碼進入 Linux 核心的主要原因之一；Con 始終無法面對使用者回報的問題，採取的態度是爭論對抗，而不是願意用心和使用者一起解決問題。"， Linus 強調朝向一個對所有層面都好的解決方案的重要性。" SD 一直沒有一個可以讓人信任的維護者，除了能專注自己的主題之外，也能關注其它層面，這便是 SD 為何會被判出局的原因。"
Linus 推崇 CFS 的開發者 Ingo Molnar 道: "相信我！ 做為一個長期的核心開發者，我最清楚什麼才是最重要的，任何能夠不怕麻煩地接受問題回報，並且持續改進的人，絕對比採取對抗問題心態者更為重要"。
Linus 也提到，我知道已有一群人正在測試 CFS 和 SD 在各種狀況下的效能比較，大部份的人應該都會同意 CFS 和 SD 會比原來使用的 0/1 排班器優秀，但 CFS 和 SD 之間卻不會有什麼重大的效能差異。
至此，情況已經很清楚了，由 Linus 的表態，我們可以了解為何 Linus 選擇 CFS 而不是 SD 的原因；Linus 希望任何一個核心開發方案，都能夠注意到其它層面，而不是只顧專注自己的主題，卻排除其它人對各核心領域可能產生影響的考量，最重要的是，開發者要能夠接受問題回報，並且持續改進它。
不管如何，這個爭論應該算是塵埃落定了，近日推出的 Linux 2.6.23-rc2 中已改用 CFS 程式碼(馬上就有人對它進行效能測試:http://www.phoronix.com/scan.php?page=article&item=797&num=1 )，這個事實說明了 Linus 的堅持，許多人應該願意相信 Linus 最終的決定應該是對的。
星期六, 9月 15, 2007
星期六, 9月 08, 2007
AMD Barcelona大幅提升虛擬化技術
AMD Barcelona大幅提升虛擬化技術
記者曠文溱／台北報導 07/09/2007
AMD的首款四核心Opteron晶片（代號為Barcelona），投注了不少心力在虛擬化技術。
在英特爾於日（7）昨發表四核心Xeon MP晶片X7300系列（代號為Tigerton），宣告虛擬化技術由處理器層級步入I/O——讓I/O資源可以分別劃分給特定的虛擬機器（VM），以加快存取速度後；AMD也宣佈即將於本（9）月13日露相的四核心Opteron晶片Barcelona，不落人後地支援多項虛擬化技術。
「虛擬化技術是Barcelona的四大重點技術之一，」AMD伺服器暨工作站事業部全球業務發展經理John Fruehe在上週表示。另外的三大方向則是節電、效能、保障客戶既有投資，即AMD一向訴諸的新款處理器可與過去平台相容。
Barcelona的其中一項虛擬化技術，類似於英特爾即將在今年底發表的45奈米製程的Penryn處理器中的「FlexMigration」。AMD的版本名為「AMD-V Extended Migration」的技術，係指讓虛擬機器（VM）在不同世代的Opteron系統上線上轉移（Live Migration）。過去倘若是不同世代的Opteron系統，必須暫時關閉應用程式的運作後，才能將虛擬機器從一台實體伺服器轉換到另外一台機器。
另外，Barcelona還包括了名為「Rapid Virtualization Indexing」的技術，宣稱前者係將存放在快取裡面的資料打上標籤，因此在虛擬機器每次載入（load）資料的時候，被打上標籤的資料可以讓處理器得知是從那個虛擬機器而來，這些索引（index）將有助於減少其他的虛擬機器載入資料時的延遲時間。
「Opteron的晶片設計整合了記憶體控制器，才能夠達到上述技術。換言之英特爾無法做到這點，」AMD說。
而另一點Barcelona對虛擬化技術的貢獻，則是彌補過去諸如VMWare等虛擬化軟體的不足。AMD表示，一名為「Nested Paging」的技術，可以讓在虛擬機器裡面的應用程式，繞過Hypervisor和硬體層溝通。
根據AMD提供的資料，2GHz的Barcelona在執行VMWare時，表現高出3GHz雙核Opteron的79%。
記者曠文溱／台北報導 07/09/2007
AMD的首款四核心Opteron晶片（代號為Barcelona），投注了不少心力在虛擬化技術。
在英特爾於日（7）昨發表四核心Xeon MP晶片X7300系列（代號為Tigerton），宣告虛擬化技術由處理器層級步入I/O——讓I/O資源可以分別劃分給特定的虛擬機器（VM），以加快存取速度後；AMD也宣佈即將於本（9）月13日露相的四核心Opteron晶片Barcelona，不落人後地支援多項虛擬化技術。
「虛擬化技術是Barcelona的四大重點技術之一，」AMD伺服器暨工作站事業部全球業務發展經理John Fruehe在上週表示。另外的三大方向則是節電、效能、保障客戶既有投資，即AMD一向訴諸的新款處理器可與過去平台相容。
Barcelona的其中一項虛擬化技術，類似於英特爾即將在今年底發表的45奈米製程的Penryn處理器中的「FlexMigration」。AMD的版本名為「AMD-V Extended Migration」的技術，係指讓虛擬機器（VM）在不同世代的Opteron系統上線上轉移（Live Migration）。過去倘若是不同世代的Opteron系統，必須暫時關閉應用程式的運作後，才能將虛擬機器從一台實體伺服器轉換到另外一台機器。
另外，Barcelona還包括了名為「Rapid Virtualization Indexing」的技術，宣稱前者係將存放在快取裡面的資料打上標籤，因此在虛擬機器每次載入（load）資料的時候，被打上標籤的資料可以讓處理器得知是從那個虛擬機器而來，這些索引（index）將有助於減少其他的虛擬機器載入資料時的延遲時間。
「Opteron的晶片設計整合了記憶體控制器，才能夠達到上述技術。換言之英特爾無法做到這點，」AMD說。
而另一點Barcelona對虛擬化技術的貢獻，則是彌補過去諸如VMWare等虛擬化軟體的不足。AMD表示，一名為「Nested Paging」的技術，可以讓在虛擬機器裡面的應用程式，繞過Hypervisor和硬體層溝通。
根據AMD提供的資料，2GHz的Barcelona在執行VMWare時，表現高出3GHz雙核Opteron的79%。
星期五, 8月 17, 2007
呈現在空氣中的 3D 影像
呈現在空氣中的 3D 影像
-- 使用雷射電漿將「真正的 3D 影像」視覺化
Three Dimensional Images in the Air
- Visualization of "real 3D images" using laser plasma -
http://www.aist.go.jp/aist_e/latest_research/2006/20060210/20060210.html
Key Points
1. 我們使用雷射所產生的電漿技術在空氣中製造閃光點（flashpoint）
2. 我們藉由最佳化雷射光束，大大地改進電漿的亮度、對比與生產距離。
3. 利用雷射電漿，我們首次成功的在空間中顯示「真正的 3D 影像」，除了空氣之外什麼都沒有。
概要
在 National Institute of Advanced Industrial Science and Technology（AIST, 總裁: Hiroyuki Yoshikawa）、慶應義塾大學（Keio University ，校長：Yuichiro Anzai）與 Burton Inc.（CEO: Hidei Kimura）的合作下，已成功完成實驗性裝置的製造，該裝置能在空間中顯示由點陣列構成的 "真正 3D 影像。"
到目前為止，大部分已報導的 3D 顯示都是在 2D 平面上利用人類雙眼視覺像差（binocular disparity）描繪假的 3D 影像。然而，這會產生許多問題，例如，有限的視野，以及因為虛擬影像錯判（misidentification）在生理上所引起的不適。
我們所開發的裝置利用已聚焦雷射光束之焦點附近的電漿放射現象。藉由控制聚焦雷射在 x-, y-, z- 軸上的位置，我們成功的顯示由空氣中的點陣列所構成的真正 3D 影像。
研究歷史
慶應義塾大學與 Burton Inc. 注意到一個現象，當雷射光束能強力聚焦時，可在焦點附近誘發空氣電漿放射。因此，它們成功地實驗性製造出一種，由點陣列（結合雷射光源與電流計鏡 [galvanometric mirrors] 所構成）所構成，能在空氣當中顯示 2D 影像的裝置。為了更進一步在空氣當中顯示3D 影像，能夠沿著雷射光軸將（雷射光）焦點在深處方向掃描（scanning）是必要的。然而，為達此目標，雷射的品質與改變焦點位置的技術都必須要改進，也因此當時並未製造出 3D 顯示裝置。
研究細節
在 AIST、慶應義塾大學與 Burton Inc. 的合作之下，在前述 2D 裝置中增添線性馬達系統；高品質、高亮度之紅外線脈衝雷射，並成功地利用這種裝置所構成的點陣列在空間當中顯示 3D 影像。
線性馬達系統讓雷射焦點的位址，能經由馬達軌道上透鏡組的高速掃描而改變。在該系統的合作之下，讓影像在 z 軸方向掃描成為可能。為了要掃 x與 y 軸方向，利用了傳統的電流計鏡。
我們在此使用的雷射光源是高品質、高亮度的紅外線脈衝雷射（脈衝重複頻率約 100 Hz），由此電漿產生可以更精確地被控制，讓更明亮、對比更高的影像能夠繪出。此外，裝置與描繪點之間的距離可大大地延展（數公尺）。
雷射脈衝的放射時間是在奈秒（10^-19 秒）等級。我們的裝置在每一點上使用一個脈衝，對此，人眼可利用視覺暫留（after-image）效應來識別出電漿放射，且能夠達到每秒 100 點的顯示。
藉由將這些脈衝同步化，並透過軟體來控制我們的裝置，我們可以在空氣中繪出任何 3D 物體。
下面是利用我們的裝置所顯示出來的各種圖形。
※ 現在該團隊有新的改進了，可以在空氣中繪出「イ」這個片假名。
＊ 産総研：プレス・リリース 「空間立体描画（３Ｄディスプレー）」技術の高性能化実験に成功
http://www.aist.go.jp/aist_j/press_release/pr2007/pr20070710/pr20070710.html
＊ AIST improves 3D projector ::: Pink Tentacle
http://www.pinktentacle.com/2007/07/aist-improves-3d-projector/
http://www.pinktentacle.com/2006/02/aist-develops-3d-image-projector/
星期三, 8月 15, 2007
The Segment Descriptor Cache
The Segment Descriptor Cache
By Robert R. Collins
It is easy to underestimate the importance of something when you don’t know what it is or how it works. As early as the 80286, all Intel x86 processors have included an entity called the "segment-descriptor cache" which works behind the scenes, hidden from you. It is updated each time a segment register is loaded. It is used for all memory accesses by all Intel x86 processors since the 80286. If you’re an end user, you’ve probably used programs that depend upon the functions of the segment-descriptor cache. If you’re an engineer, there is a high probability that you’ve relied upon the functions of the segment-descriptor cache – and you might not have realized it. If you’re an engineer who writes any low-level code, programs hardware, or programs in protected mode, then you should be aware of the segment-descriptor cache and how it works.
From the 80286 to 80486, the meaning of "segment-descriptor cache" was unambiguous, referring to an internal microprocessor structure that stores the internal representation of the segment registers. This representation includes the segment base address, limit, and access rights. With the Pentium, Intel introduced a 94-entry, two-way set associative cache of segment-descriptor cache entries. Therefore, the phrase "segment-descriptor cache" is now ambiguous, with two possible meanings. Making matters worse, the new segment-descriptor cache was removed from the Pentium Pro design, but reintroduced in the Pentium II. (The lack of the new segment-descriptor cache in the Pentium Pro largely accounted for its poor 16-bit performance.) In this column, I’ll discuss the original segment-descriptor cache that has existed since the 80286 (and remains in all modern Intel x86 processors) and the role of the segment-descriptor cache in microprocessor memory management.
Loading Descriptor Cache Registers
Whether in real, protected, virtual-8086, or system-management mode, the microprocessor stores the base address of each segment in a hidden descriptor-cache registers. Each time a segment register is loaded, the segment-base address, segment-size limit, and segment-access attributes (access rights) are loaded (cached) into these hidden registers. To enhance performance, subsequent memory references are made via the descriptor-cache registers. Without this optimization, each memory access would require the microprocessor to perform many time-consuming tasks. In real mode, the microprocessor would need to calculate the physical address from the segment register value. The access rights would always indicate a read/write data segment (even for the code segment). The limit would always be 64 KB of memory. In protected mode, the segment base must be looked up in the appropriate descriptor table. The segment base is composed of a combination of fields in the descriptor table. The segment access rights and segment limit are also contained in the descriptor table. The microprocessor would need to access those structures for each memory access. These descriptor-table values reside in memory, where accesses tend to be slow when compared to accesses within the microprocessor. Therefore, without an internal segment-descriptor cache to cache these values, each memory access would implicitly require many other accesses to memory.Now consider the differences between real mode and protected mode. If the segment descriptor cache didn’t exist, determining segment base, limit, and access rights would require more than one CPU cycle to complete. Therefore, the segment-descriptor cache exists to eliminate these potential deficiencies. It exists to allow all of these differences to be resolved at the time each segment is loaded. The performance penalty is incurred only once. Thereafter, all memory management is performed according to the values in the segment descriptor caches for each respective segment register.
At power-up, the descriptor-cache registers are loaded with fixed, default values – the CPU is in real mode, and all segments are marked as read/write data segments, including the code segment (CS). According to Intel, each time any segment register is loaded in real mode, the base address is calculated as 16 times the segment value, while the access rights and size limit attributes are given fixed, "real-mode compatible" values. This is not true. In fact, only the CS descriptor caches for the 286, 386, and 486 get loaded with fixed values each time the segment register is loaded. Loading CS, or any other segment register in real mode, on later Intel processors doesn’t change the access rights or the segment size limit attributes stored in the descriptor cache registers. For these segments, the access rights and segment size limit attributes from any previous setting are honored. Thus, it is possible to have a four-GB read-only data segment in real mode on the 80386 – but Intel won’t acknowledge this mode of operation, though it is implicitly supported. Furthermore, Intel can’t remove it without rendering many software programs ineffective.
Protected mode differs from real mode in this respect: As each time a segment register is loaded, the descriptor cache register gets fully loaded; no values are honored. The descriptor cache is loaded directly from the descriptor table. The CPU checks the validity of the segment by testing the access rights in the descriptor table. Complete checks are made, and illegal values will generate exceptions. Any attempt to load CS with a read/write data segment will generate a protection error. Likewise, any attempt to load a data segment register as an executable segment will also generate an exception. The CPU strictly enforces these protection rules. If the descriptor-table entry passes all the tests, then the descriptor-cache register gets loaded.
Format of Descriptor Cache Registers
The layout of the segment-descriptor cache registers change with almost every processor generation, though their functions do not. These differences are known as "implementation specific" because their exact layout and contents depend on the design and implementation of the microprocessor. For the most part, the fields of the segment-descriptor cache mirror the fields in the protected mode descriptor table. For 32-bit descriptor-table entries, the segment-base address, segment-access rights, and segment-limit fields are not contiguous. These related fields are combined before being put in the segment-descriptor cache. Figure 1 shows the relationship between fields in the descriptor table and segment-descriptor cache.
Figure 1: Combining fields from the descriptor table into the segment-descriptor cache.
| Offset |
63..56
|
55
|
54
|
53
|
52
|
51..48
|
47
|
46..45
|
44
|
43..40
|
39..16
|
15..00
|
| Description |
Base[31:24]
|
G
|
D/B
|
0
|
AVL
|
Limit[19:16]
|
P
|
DPL
|
S
|
Type
|
Base[23:00]
|
Limit[15:00]
|
| Segment Base | Segment Access Rights | Segment Limit |
Segment-Descriptor Cache
It is useful to know the layout of the fields inside the segment-descriptor cache. The segment base and segment limit are always combined from the descriptor table to form a complete base address and segment limit inside the segment-descriptor cache. The format of the access rights within the segment-descriptor cache changes from implementation to implementation. Likewise, the order of the fields within the cache can change. Regardless, knowing the format of the segment-descriptor cache can make you more productive, reducing both development and debugging time. Tables 1 through 4 show the descriptor cache entry format for all Intel x86 processors from the 80286 through Pentium Pro.
Table 1 - 80286 Descriptor Cache Entry
| Bit Position | 47..32 | 31 | 30..29 | 28 | 27..24 | 23..00 |
| Description | 16-bit Limit | P | DPL | S | Type | 24-bit Base |
Table 2 - 80386 and 80486 Descriptor Cache Entry
| Bit Position | 95..64 | 63..32 | 31..24 | 23 | 22..21 | 20 | 19..16 | 15 | 14 | 13..0 |
| Description | 32-bit Limit | 32-bit Base | 0 | P | DPL | S | Type | 0 | D / B | 0 |
Table 3 - Pentium Descriptor Cache Entry
| Bit Position | 95..79 | 78 | 77..72 | 71 | 70..69 | 68 | 67..64 | 63..32 | 31..00 |
| Description | 0 | D/B | 0 | P | DPL | S | Type | 32-bit Base | 32-bit Limit |
Table 4 - Pentium Pro Descriptor Cache Entry
| Bit Position | 95..64 | 63..32 | 31 | 30 | 29..24 | 23 | 22..21 | 20 | 19..16 | 15..00 |
| Description | 32-bit Base | 32-bit Limit | 0 | D/B | 0 | P | DPL | S | Type | Segment Selector |
Descriptor-Cache Registers In Real Life
There are different ways to take advantage of the segment-descriptor cache registers. System-management mode (SMM) gives you direct control over each field in the segment-descriptor cache. (See my DDJ January/March/May 1997 columns for an in-depth look at System Management Mode.) In-circuit emulators (ICEs) also allow direct control over each field in the segment descriptor cache. (Refer to my DDJ July/September/November 1997 columns for information on in-circuit emulation.)For instance, when writing any low-level assembly-language programs (such as OS kernels, device drivers, BIOS, or protected-mode programming), I make common, simple mistakes. I sometimes make a mistake when creating my segment descriptor table, usually the Global Descriptor Table (GDT). I may have created the GDT using an incorrect base address, segment limit, or access rights. Ultimately, my program fails, and I must use the ICE as a debugging tool. I’ll then insert the undocumented ICEBP instruction into my code to instruct the ICE to breakpoint at the suspected point of failure (see http://www.x86.org/secrets/opcodes/ICEBP.html). Within moments, I discover that I used incorrect values in building the descriptor table. Using the ICE, I can load each field of the segment-descriptor cache. If I used an incorrect segment base address, I can correct it and continue. Likewise, I can make the same corrections for the segment limit and segment access rights. I know that these values are "sticky," meaning that they don’t get changed until a new segment register value is loaded. Therefore, I can make these changes, and continue debugging my program. Using this technique, I can usually discover six or more bugs in my program before recompiling. Because I don’t need to recompile my program after discovering each and every mistake, I save valuable development and debugging time.
Programming in SMM implicitly takes advantage of the segment-descriptor cache registers. The segment-descriptor cache registers are saved and restored along with the remaining microprocessor state in the SMM state save map. These values are saved and restored upon entry and exit to system-management mode. In my March 1997 DDJ column, I disclosed all of the undocumented fields (known as "reserved" fields in Intel parlance) in the Pentium SMM state save map. As I discussed, the segment-descriptor cache registers are stored in these reserved fields.
It is possible to manipulate these segment-descriptor cache values from within the SMM handler. The segment base may be changed to a value that is inconsistent with its associated segment register value. The segment access rights may be manipulated to give current-privilege-level-3 (CPL-3) tasks CPL-0 access (an obvious breach of security). The segment limit may be changed to create a segment with a four-GB limit while in real mode. Using SMM, it is possible to change the segment attributes to values that are programmatically impossible; for example, a real-mode segment at two MB, a segment limit size of 4-gigabytes minus 16, or a read/write code segment in protected mode (not to mention CPL-0 access within a CPL-3 task).
Descriptor Cache Anomalies and creating "Unreal Mode"
Using either of these methods to manipulate segment-descriptor caches can be challenging. However, there’s another programatic way of putting segment-descriptor caches to work – creating a CPU operating mode known as "unreal" mode.Unreal mode is created when a real-mode segment has a four-GB segment limit. Unreal mode can be created without any hardware debuggers or SMM programming with a simple assembly-language program. Imagine a program that begins in real mode then transitions into protected mode. Once in protected mode, the program loads all of the segment registers with descriptors containing four-GB segment limits. After setting the segment limits, return immediately to real mode without restoring the segment registers to segments containing 64-KB segments (real-mode-compatible segments). Once in real mode, the segment limits will always retain their four-GB limits. Thereafter, DOS programs can take advantage of the entire 32-bit address space without resorting to protected-mode programming.
Unreal mode has been used commonly since it was discovered on the 80386. Unreal mode is so commonly used, in fact, that Intel has been forced to support this mode as part of legacy 80x86 behavior, though it’s never been documented. Memory managers and games often take advantage of unreal mode. Source code that demonstrates how you can create unreal mode is available electronically from DDJ (see "Resource Center,") or at ftp://ftp.x86.org/dloads/UNREAL.ZIP.
The real-mode code segment (CS) descriptor cache behavior has changed between generations of Intel processors. The role of the code segment-descriptor cache in real mode differs between the 80286, 80386, and 80486 and all later Intel microprocessors: The earlier microprocessors honor the real-mode segment access rights in real mode until a far control transfer occurs; later processors ignore any access rights in the CS descriptor cache irrespective of far control transfers. On the earlier processors, any far control transfer set the CS descriptor cache access rights to its real-mode compatible value as a readI-write data segment (value=0x93). Later processors leave the original value intact, but ignore its contents. Therefore, transitions from real to protected mode on the later processors immediately causes the behavior to revert to its stagnant CS descriptor-cache access rights value. On earlier processors, the CS limit is also restored to its real-mode compatible value (64 KB). Later processors leave the CS segment limit alone, making its behavior consistent with the other data segment registers.
From the 80286 to the Pentium, all Intel processors derive their current privilege level (CPL) from the SS access rights. The CPL is loaded from the SS descriptor table entry when the SS register is loaded. The undocumented LOADALL instruction (or system-management mode RSM instruction) can be used to manipulate the SS descriptor-cache access rights, thereby directly manipulating the CPL of the microprocessors. (See http://www.x86.org/articles/loadall/ for a description of LOADALL.) The Pentium Pro behaves differently: Once the CPL is loaded into the Pentium Pro, it is not internally derived from the SS access rights. The Pentium Pro retains a separate CPL register. Through the system-management mode RSM instruction, you can directly manipulate the CPL of the Pentium Pro, though not by manipulating the SS access rights value. (I will discuss the Pentium Pro SMM state save map and all of the secrets contained therein in a future column.)
Conclusion
I use the segment-descriptor cache registers every day – when I’m debugging on my ICE to help correct common protected-mode programming errors, programming in system-management mode to create events, or creating real-mode segments that can address the entire four-GB address space. The use of the segment-descriptor cache is highly implementation specific, meaning the behavior and layout of the segment-descriptor cache is dependant upon the implementation of the specific microprocessor. Intel doesn’t guarantee that the behavior of the descriptor cache will remain the same from microprocessor to microprocessor. Therefore, it would be foolhardy to write any production-quality source code which depends upon this behavior (except unreal mode).
星期日, 8月 12, 2007
完善的IT服務管理，ITIL、CMMI、COBIT等應納入考慮
‧IBM： ITIL不是IT服務管理的唯一聖經
| 記者馬培治／台北報導 10/08/2007 |
面對近來相當熱門的ITIL話題，藍色巨人IBM認為，要做好完善的IT服務管理，除了ITIL，CMMI、COBIT等標準也應納入考慮。
近日來由於itSMF（IT服務管理論壇）台灣分會成立，加上ITIL(IT Infrastructure Library, IT基礎架構集成)第三版的推出，ITIL一時之間成為廠商與企業間的熱門話題，CA、BMC與HP上個(7)月以來更相繼舉辦關於ITIL的活動，總共 吸引逾千位企業代表出席。不過，按兵不動的IBM認為，ITIL登上話題熱潮固然有助於市場推廣，但更強調「做好IT服務管理，CMMI與COBIT等標 準也應納入考慮，」IBM高層表示。
「企業應該評估目前需要提升的IT服務管理領域，選擇適合的標準遵行，」IBM架構服務與IT策略執行顧問Michael Shallcross表示，IT服務管理應該從使用者的角度，來決定採行的標準。他解釋道，若企業IT服務重點在營運面(operational)， ITIL便很適合；但若企業IT的主要使用者是開發，則應採CMMI（Capability Maturity Model- Integrated，能力成熟度整合模式）；若是治理或規劃，則為COBIT（Control Objectives for Information and related Technology，資訊與相關技術控制目標）。
 |
IBM全球IT服務事業部顧問經理陳俊昌則說，IBM自1983年以來便已自行發展一套專屬的ITSM架構與方法論，此外也參與ITIL相關標準的制定與出版品編寫，「ITIL只是ITSM的一環，企業可以依據自身發展狀況與需求，同時採用諸多標準的精華，」他說。
ITSM(IT Service Management, IT服務管理)為1980年代英國商務部(OGC)提出的概念，是在將IT視為服務的前提下，透過管理的手段，來提升、確保IT服務的品質。OGC與並據 此發展出ITIL架構，欲以流程與方法論協助企業達到良好ITSM的目標。也因為ITIL是針對ITSM所制定而成，使得一般企業一聽到ITSM，便會自 然想到ITIL。
不過由於IT服務定義廣泛，軟體開發、IT治理等亦會影響IT服務品質的內容，也因此被認為應納入ITSM的範圍，這也是為什麼IBM認為CMMI與COBIT的應與ITIL一併列入ITSM範圍的理由。
研究機構IDC企業應用研究經理曹永暉回應IBM的說法表示，ITIL是達到良好ITSM的途徑之一，但不是全部。
「但國內企業偏好採用既存的標準，因此一提到ITSM，企業往往會先想到ITIL，」曹永暉認為，ITIL雖以最佳實務(Best Practice)的觀點提供企業提升ITSM的準則，但畢竟沒有兩家企業是完全相同，他認為，與其追隨單一標準，企業不妨以ITIL架構為基礎，發展自 有的IT服務管理流程。
其它業者亦認同ITIL不是絕對，但確是進行ITSM很好的參考準則。CA資深技術顧問江禎義便說，要做到良好的ITSM，ITIL當然不是惟一的途徑，但他認為，對於沒有資源自行開發管理流程的企業來說，「有現成的標準可參考，會比較容易，」他說。
不過，對IBM提出CMMI與COBIT等標準亦應納入企業ITSM規劃，曹永暉認為，其他廠商未必不知道ITSM包含範圍不止ITIL，而是市場行銷的 考量問題。他認為，IBM同時提出ITIL、COBIT與CMMI，有利於產品的整合銷售，「不是每家推廣ITIL的廠商，產品都像IBM一樣完整，」曹 永暉說。
Linux 2.6 的 System Call：12 大類
‧Linux 2.6 的 System Call：12 大類
jollen 發表於 October 11, 2006 2:58 PM /本文出處: www.jollen.org 已取得原作者授權使用
jollen 發表於 October 11, 2006 2:58 PM /本文出處: www.jollen.org 已取得原作者授權使用
把 Linux 提供的 sytsem call service 依分類做整理，並提供實作檔案。本表使用於 Jollen 的「2. GNU Toolchains 與 Embedded Linux Programming」課程中，在此提供給大家做參考。目前依據 Linux 2.6.11 原始碼製成，請搭配 2.6.11 以上的版本做研究。
--jollen
訂閱：
文章 (Atom)