Linux開發者越來越多,但是仍然有很多人整不明白POSIX是什么。本文就帶著大家來了解一下到底什么是POSIX,了解他的歷史和重要性。
一、什么是posix?
1. 概念
POSIX:可移植操作系統接口(Portable Operating System Interface of UNIX,縮寫為 POSIX ),
2. 發布者-IEEE
發布者為電氣與電子工程師協會(Institute of Electrical and Electronics Engineers),簡稱IEEE。這個協會老牛了【該組織在太空、計算機、電信、生物醫學、電力及消費性電子產品等領域中都是主要的權威】!
POSIX是IEEE為要在各種UNIX操作系統上運行的軟件而定義的一系列API標準的總稱,其正式稱呼為IEEE 1003,而國際標準名稱為ISO/IEC 9945。
POSIX.1 已經被國際標準化組織(International Standards Organization,ISO)所接受,被命名為 ISO/IEC 9945-1:1990 標準。
IEEE,總部位于美國紐約,是一個國際性的電子技術與信息科學工程師的協會,也是目前全球最大的非營利性專業技術學會。IEEE致力于電氣、電子、計算機工程和與科學有關的領域的開發和研究,在太空、計算機、電信、生物醫學、電力及消費性電子產品等領域已制定了1300多個行業標準,現已發展成為具有較大影響力的國際學術組織
3. POSIX標準下載
很多人聽說了POSIX標準,但標準具體長什么樣,在哪里下載到,則 不清楚。現在我開放出來,供相關人員使用。
Single UNIX Specification V3,IEEE Std 1003.1,2004 Edition
標準線上地址:
http://www.unix.org/version3/online.html
注冊后可以在線閱讀或者下載。
IEEE和Open Group 的POSIX認證:
http://www.opengroup.org/certification/idx/posix.html
相關頁面:
http://www.unix.org/version3/ieee_std.html
二、POSIX歷史
1. 起源
POSIX是Unix的標準。
1974年,貝爾實驗室正式對外發布Unix。因為涉及到反壟斷等各種原因,加上早期的Unix不夠完善,于是貝爾實驗室以慷慨的條件向學校提供源代碼,所以Unix在大專院校里獲得了很多支持并得以持續發展。
于是出現了好些獨立開發的與Unix基本兼容但又不完全兼容的OS,通稱Unix-like OS。
包括:
20世紀80年代中期,Unix廠商試圖通過加入新的、往往不兼容的特性來使它們的程序與眾不同。
局面非常混亂,麻煩也就隨之而來了。
為了提高兼容性和應用程序的可移植性,阻止這種趨勢, IEEE(電氣和電子工程師協會)開始努力標準化Unix的開發,后來由 Richard Stallman命名為“Posix”。
這套標準涵蓋了很多方面,比如Unix系統調用的C語言接口、shell程序和工具、線程及網絡編程。
2. 誰遵循這個標準呢?
首先就是大名鼎鼎的Unix和Linux了,
除此之外還有蘋果的操作系統也是Unix-based的。
有了這個規范,你就可以調用通用的API了,Linux提供的POSIX系統調用在Unix上也能執行,因此學習Linux的底層接口最好就是理解POSIX標準。
Windows從WinNT開始就有兼容POSIX的考慮。這是因為當年在要求嚴格的領域,Unix地位比Windows高。為了把Unix用戶拉到Windows陣營,被迫支持POSIX。
現在Win10對 Linux/POSIX 支持好,則是因為Linux已經統治了廉價服務器市場。為了提高Windows的競爭力搞的。
所以一切都是以市場為主導。
3. 支持POSIX-Linux成功的最重要一個因素
Linux之所以能夠成功,有很多因素,但是支持POSIX標準無疑是它能夠快速發展的最重要的一個因素。
POSIX 標準的制定最后投票敲定階段大概是 1991~1993 年間,而此時正是Linux 剛剛起步的時候,這個 UNIX 標準為 Linux 提供了極為重要的信息,使得 Linux 能夠在標準的指導下進行開發,并能夠與絕大多數 UNIX 操作系統兼容。
在最初的 Linux 內核源碼(0.01版、0.11版)中就已經為 Linux 系統與 POSIX 標準的兼容做好了準備工作。
在 Linux 0.01 版內核 /include/unistd.h 文件中就已經定義了幾個有關 POSIX 標準要求的符號常數,而且 Linus 在注釋中已寫道:“OK,這也許是個玩笑,但我正在著手研究它呢”。
正是由于Linux支持POSIX標準,無數可以在unix上運行的程序都陸續的移植到Linux上,而此時unix因為版權問題,官司打的不可開交,使得Linux后來者居上。
時也命也!
下面是祖師爺Linus當年申請POSIX標準的郵件:
來自:torvalds@klaava.Helsinki.Fi(林納斯·托瓦茲)
討論組:comp.os.minix
主題:Gcc-1.40和一個有關POSIX的問題
信息名稱:1991 Jul 3, 100050.9886@klaava.Helsinki.Fi
日期:1991年7月3日, 格林威治時間10:00:50各位網友好!
由于我現在正在MINIX系統下做一個項目, 對POSIX標準很感興趣。有誰能向我提供
一個(最好) 是機器可讀形式的最新的POSIX規則?能有FTP地址就更好了。
而Linus也在《知識為了好玩》中講述了POSIX的重要性:
POSIX標準是一個可以適用于數以百計的UNIX系統呼叫中的任意一個的一套冗長規則, 計算機要執行任務(從讀、 寫、 開機和關機開始) 就需要這個標準。
POSIX則是指一個UNIX的標準體系, 或一個由來自不同公司的代表所組成的一個組織, 希望按照一個共同的標準進行運作。對于程序員開發的在該操作系統下的新應用軟件或開發應用軟件的新版本而言, 標準是極其重要的。從POSIX這樣的系統呼叫(system call) , 尤其是重要的呼叫(call) 中, 我可以獲得一個操作系統應該具有哪些功能的一個單子;然后我就可以通過自己的方式在自己的系統中實現每一個功能。通過編寫出這些標準, 我的系統軟件的源代碼將可以被別人使用, 以開發新的應用軟件。
當時我并不知道我本可以直接從POSIX公司買到這些規則的軟盤, 但這無所謂。哪怕我能買得起, 什么東西運到芬蘭, 往往會需要很長的時間。我不愿等上那么久, 因此我四處搜求一個能從FTP地址上直接下載的版本。
沒有人給我提供能找到POSI標準的來源。于是我開始了計劃B。
我從學校找到運行sun器(sun server)的sun微系統版的UNIX手冊。該手冊中有一個完全可以湊合使用的系統呼叫的基本版本。從用戶手冊中能看出系統呼叫的主要功能, 以及為完成這些功能所需要完成的步驟。但是, 從中看不出具體的方法, 而只是標明了最終的結果。于是我便著手從安德魯·塔南鮑姆的書中和別的材料中收集一些系統呼叫。
最終有人給我寄來了那幾卷厚厚的POSIX標準。
三、可移植性
聊到POSIX,那我們就不得不說說到底什么是可移植性,在講可移植性之前,我們先來了解庫函數和系統調用的區別。
Linux下對文件操作有兩種方式:系統調用(system call)和庫函數調用(Library functions)。
1. 系統調用
系統調用是通向操作系統本身的接口,是面向底層硬件的。通過系統調用,可以使得用戶態運行的進程與硬件設備(如CPU、磁盤、打印機等)進行交互,是操作系統留給應用程序的一個接口。
2. 庫函數
庫函數(Library function)是把函數放到庫里,供別人使用的一種方式。
方法是把一些常用到的函數編完放到一個文件里,供不同的人進行調用。一般放在.lib文件中。
庫函數調用則是面向應用開發的,庫函數可分為兩類,
-
一類是C語言標準規定的庫函數,
-
一類是編譯器特定的庫函數。
(由于版權原因,庫函數的源代碼一般是不可見的,但在頭文件中你可以看到它對外的接口)。
glibc 是 Linux 下使用的開源的標準 C 庫,它是 GNU 發布的 libc 庫,即運行時庫。這些基本函數都是被標準化了的,而且這些函數通常都是用匯編直接實現的。
glibc 為程序員提供豐富的 API(Application Programming Interface),這些API都是遵循POSIX標準的,API的函數名,返回值,參數類型等都必須按照POSIX標準來定義。
POSIX兼容也就指定這些接口函數兼容,但是并不管API具體如何實現。
3. 庫函數API和系統調用的區別
如上圖所示:
-
(1) 庫函數是語言或應用程序的一部分,而系統調用是內核提供給應用程序的接口,屬于系統的一部分
-
(2) 庫函數在用戶地址空間執行,系統調用是在內核地址空間執行,庫函數運行時間屬于用戶時間,系統調用屬于系統時間,庫函數開銷較小,系統調用開銷較大
-
(3) 系統調用依賴于平臺,庫函數并不依賴
系統調用是為了方便使用操作系統的接口,而庫函數則是為了人們編程的方便。
庫函數調用與系統無關,不同的系統,調用庫函數,庫函數會調用不同的底層函數實現,因此可移植性好。
4. 程序的可移植性及其本質
那么目標代碼和啟動代碼是怎么生成的呢?
答案是編譯器。
編程語言編寫的程序首先要被編譯器編譯成目標代碼(0、1代碼),然后在目標代碼的前面插入啟動代碼,最終生成了一個完整的程序。
要注意的是,程序中為訪問特定設備(如顯示器)或者操作系統(如windows xp 的API)的特殊功能而專門編寫的部分通常是不能移植的。
綜上所述,一個編程語言的可移植性取決于
-
不同平臺編譯器的數量
-
對特殊硬件或操作系統的依賴性
移植是基于操作系統的。但是這個時候,我們需要注意一點:基于各種操作系統平臺不同,應用程序在二級制級別是不能直接移植的。
我們只能在代碼層去思考可移植問題,在API層面上由于各個操作系統的命名規范、系統調用等自身原因,在API層面上實現可移植也是不大可能的。
在各個平臺下,我們默認C標準庫中的函數都是一樣的,這樣基本可以實現可移植。但是對于C庫本身而言,在各種操作系統平臺下其內部實現是完全不同的,也就是說C庫封裝了操作系統API在其內部的實現細節。
因此,C語言提供了我們在代碼級的可移植性,即這種可移植是通過C語言這個中間層來完成的。
例如在我們的代碼中下功夫。以下代碼可以幫助我們實現各平臺之間的可移植:
#ifdef _WINDOWS_
CreateThread(); //windows下線程的創建#else
Pthread_create(); //Linux下線程的創建#endif
對于頭文件,也使用同樣的預編譯宏來實現。如:
#ifndef _WINDOWS_
#include #else
#include #endif
這樣就可以實現代碼的可移植了。在編譯的時候只要通過#define就可以選擇在那個平臺下完成程序的編譯。
綜上所述,我們都是將C,C++等各種語言當作中間層,以實現其一定程度上的可移植。如今,語言的跨平臺的程序都是以這樣的方式實現的。但是在不同的平臺下,仍需要重新編譯。
5. 系統開銷
使用系統調用會影響系統的性能,在執行調用時的從用戶態切換到內核態,再返回用戶態會有系統開銷。
為了減少開銷,因此需要減少系統調用的次數,并且讓每次系統調用盡可能的完成多的任務。
硬件也會限制對底層系統調用一次所能寫的數據塊的大小。
為了給設備和文件提供更高層的接口,Linux系統提供了一系列的標準函數庫。
使用標準庫函數,可以高效的寫任意長度的數據塊,庫函數在數據滿足數據塊長度要求時安排執行底層系統調用。
一般地,操作系統為了考慮實現的難度和管理的方便,它只提供一少部分的系統調用,這些系統調用一般都是由C和匯編混合編寫實現的,其接口用C來定義,而具體的實現則是匯編,這樣的好處就是執行效率高,而且,極大的方便了上層調用。
隨著系統提供的這些庫函數把系統調用進行封裝或者組合,可以實現更多的功能,這樣的庫函數能夠實現一些對內核來說比較復雜的操作。
比如,read()函數根據參數,直接就能讀文件,而背后隱藏的比如文件在硬盤的哪個磁道,哪個扇區,加載到內存的哪個位置等等這些操作,程序員是不必關心的,這些操作里面自然也包含了系統調用。
而對于第三方的庫,它其實和系統庫一樣,只是它直接利用系統調用的可能性要小一些,而是利用系統提供的API接口來實現功能(API的接口是開放的)。
四、舉例
如下圖是Linux系統調用的大概流程。
當應用程序調用printf()函數時,printf函數會調用C庫中的printf,繼而調用C庫中的write,C庫最后調用內核的write()。
而另一些則不會使用系統調用,比如strlen, strcat, memcpy等。
printf函數執行過程中,程序運行狀態切換如下:
用戶態–>系統調用–>內核態–>返回用戶態
printf函數、glibc庫和系統調用在系統中關系圖如下:
實例代碼如下:
1 #include
2
3
4 int main(int argc, char **argv) 5 { 6 printf("yikoulinux
");
7 return 0; 8 }
編譯執行
root@ubuntu:/home/peng/test# gcc 123.c -o runroot@ubuntu:/home/peng/test# strace ./run
如執行結果可知:
我們的程序雖然只有一個printf函數,但是在執行過程中,我們前后調用了execve、access、open、fstat、mmap、brk、write等系統調用。
其中write系統調用會把字符串:yikoulinux通過設備文件1,發送到驅動,該設備節點對應終端stdout。
【注意】運行程序前加上strace,可以追蹤到函數庫調用過程
審核編輯 :李倩
-
Linux
+關注
關注
87文章
11320瀏覽量
209841 -
源代碼
+關注
關注
96文章
2946瀏覽量
66801 -
Posix
+關注
關注
0文章
36瀏覽量
9503
原文標題:posix是什么都不知道,還好意思說你懂Linux?
文章出處:【微信號:LinuxDev,微信公眾號:Linux閱碼場】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論