หลักสูตรนี้จะตรวจสอบมาตรฐานสำหรับอินเทอร์เฟซระบบปฏิบัติการมือถือ (POSIX) ตลอดจนเทคนิคและวิธีการสำหรับแอปพลิเคชันการเขียนโปรแกรมตามมาตรฐานนี้ โดยมีตัวอย่างมากมายแสดงตัวอย่าง คำถามเกี่ยวกับการเขียนโปรแกรมของระบบหลายกระบวนการ การโต้ตอบของแอปพลิเคชันภายในกรอบของการกำหนดค่าแบบกระจายจะถูกกล่าวถึง ให้ความคล่องตัว (พกพา, พกพา) ซอฟต์แวร์(PO) - งานที่มีความสำคัญและซับซ้อนเป็นพิเศษ ทุกวันนี้ สถานการณ์นี้แทบไม่ต้องการเหตุผลใดๆ เลย หนึ่งในวิธีที่ยอมรับกันโดยทั่วไปในการเพิ่มความคล่องตัวของซอฟต์แวร์คือการสร้างมาตรฐานให้กับสภาพแวดล้อมของแอปพลิเคชัน: อินเทอร์เฟซซอฟต์แวร์ ยูทิลิตี้ และอื่นๆ ที่เป็นที่ยอมรับ ที่ระดับของบริการระบบ สภาพแวดล้อมดังกล่าวได้รับการอธิบายโดยมาตรฐาน POSIX (อินเทอร์เฟซระบบปฏิบัติการแบบพกพา) ชื่อนี้ได้รับการแนะนำโดยผู้เชี่ยวชาญที่มีชื่อเสียง Richard Stallman ผู้ก่อตั้ง Free Software Foundation

หลักสูตรนี้ตรวจสอบเวอร์ชันที่ทันสมัยที่สุดในฉบับปี 2546 ซึ่งสามารถเรียกได้ว่าเป็น "มาตรฐานสามมาตรฐาน" กล่าวคือ: มาตรฐาน IEEE Std 1003.1 มาตรฐานทางเทคนิค Open Group และที่สำคัญที่สุดสำหรับเราคือ ISO / IEC 9945 สากล มาตรฐาน ของหลักสูตรนี้เกี่ยวกับการทำความเข้าใจเทคนิคและวิธีการใช้ยูทิลิตี้และฟังก์ชันที่ได้มาตรฐาน เป้าหมายไม่ใช่เพื่อบอกมาตรฐานซ้ำ เน้นรายละเอียดปลีกย่อยทั้งหมดของการใช้งาน OS รหัสข้อผิดพลาดที่เป็นไปได้ทั้งหมด ฯลฯ ในความเห็นของเรา สิ่งสำคัญคือต้องรู้สึกถึงจิตวิญญาณของมาตรฐาน เพื่อเรียนรู้ที่จะใช้ความเป็นไปได้ที่มีอยู่ในนั้นในแบบเคลื่อนที่ สมมติว่าผู้อ่านใช้ภาษา C ได้คล่อง เราไม่ได้พิจารณาถึงฟังก์ชันไวยากรณ์หรือไลบรารีตำราเรียน สำหรับภาษาคำสั่งมาตรฐานและล่าม หัวข้อนี้มีการอธิบายในรายละเอียดบางอย่าง แม้ว่าโปรแกรมเมอร์ฝึกหัดจำนวนมากชอบใช้ล่ามอื่น มีการยกตัวอย่างสถานที่สำคัญทั้งในแง่ของปริมาณและบทบาท บทบัญญัติหลายประการของมาตรฐาน (เกี่ยวกับการจัดการสถานการณ์ข้อผิดพลาด) ไม่ได้ระบุไว้ในข้อความหลัก แต่ในตัวอย่างที่เกี่ยวข้อง ข้อหลัง เมื่อใดก็ตามที่เป็นไปได้ ถูกรวบรวมและดำเนินการบนแพลตฟอร์มฮาร์ดแวร์และซอฟต์แวร์หลายตัวรวมกันเป็นหนึ่ง ปริญญาหรืออื่น ๆ ที่อ้างว่าเป็นไปตามมาตรฐาน POSIX อย่างไรก็ตาม การกำกับดูแลเป็นไปได้อย่างแน่นอน เราจะขอบคุณสำหรับความคิดเห็นและข้อเสนอแนะทั้งหมดที่เกี่ยวข้องกับทั้งหลักสูตรโดยรวมและตัวอย่างโปรแกรมแต่ละรายการ

ประวัติการสร้างและสถานะปัจจุบันของมาตรฐาน POSIX

การดูแลให้ความคล่องตัว (การพกพา การพกพา) ของซอฟต์แวร์ (SW) เป็นงานที่มีความสำคัญและซับซ้อนเป็นพิเศษ ในสมัยของเรา สถานการณ์นี้แทบไม่ต้องการเหตุผลมากมาย วิธีหนึ่งที่เป็นที่ยอมรับโดยทั่วไปในการเพิ่มความสามารถในการพกพาของซอฟต์แวร์คือการสร้างมาตรฐานให้กับสภาพแวดล้อมของแอปพลิเคชัน: API ที่จัดเตรียมให้ โปรแกรมอรรถประโยชน์ ฯลฯ ที่ระดับของบริการระบบ สภาพแวดล้อมดังกล่าวได้รับการอธิบายโดยมาตรฐาน POSIX (อินเทอร์เฟซระบบปฏิบัติการแบบพกพา) ชื่อนี้ได้รับการแนะนำโดย Richard Stallman ผู้เชี่ยวชาญที่มีชื่อเสียง ผู้ก่อตั้ง Free Software Foundation

หน้าชื่อเรื่อง.
เอาท์พุต
การบรรยาย 1. แนวคิดพื้นฐานและแนวคิดของมาตรฐาน POSIX
บรรยาย 2. ภาษาเปลือก.
การบรรยายที่ 3 ยูทิลิตี้และฟังก์ชั่นที่ให้บริการตามแนวคิดของ "ผู้ใช้"
การบรรยาย 4. การจัดระเบียบระบบไฟล์
การบรรยาย 5. ไฟล์อินพุต / เอาต์พุต
การบรรยาย 6. เครื่องมือสำหรับการประมวลผลข้อมูลที่มีโครงสร้าง
การบรรยาย 7. กระบวนการ.
การบรรยายที่ 8 หมายถึงการสื่อสารระหว่างกระบวนการ
การบรรยาย 9. ส่วนต่อประสานเทอร์มินัลทั่วไป
การบรรยายครั้งที่ 10. การซักถามคุณสมบัติของโฮสต์และการใช้งานในแอปพลิเคชัน
การบรรยายครั้งที่ 11 สิ่งอำนวยความสะดวกเครือข่าย
การบรรยายครั้งที่ 12. เวลาและทำงานกับเขา
การบรรยายครั้งที่ 13 สภาพแวดล้อมทางภาษาและวัฒนธรรม
การบรรยายครั้งที่ 14. บทสรุป.
บรรณานุกรม.

ดาวน์โหลดฟรี e-bookในรูปแบบที่สะดวก ดูและอ่าน:
ดาวน์โหลดหนังสือการเขียนโปรแกรมในมาตรฐาน POSIX ตอนที่ 1 Galatenko V.A. , 2016 - fileskachat.com ดาวน์โหลดเร็วและฟรี

POSIX และ RV OS: ความพยายามในการจัดระบบ

เซอร์เกย์ โซโลตาเรฟ, นิโคเลย์ กอร์บูนอฟ

จุดประสงค์ของบทความนี้คือความพยายามที่จะสร้างความกระจ่างให้กับประวัติศาสตร์ของการพัฒนามาตรฐาน POSIX ที่ใช้กับระบบปฏิบัติการแบบเรียลไทม์ (RT OS)

เป็นการแนะนำ: เหตุใดจึงต้องมีการกำหนดมาตรฐานอินเทอร์เฟซซอฟต์แวร์

หนึ่งในคุณสมบัติที่สำคัญที่สุดของมาตรฐาน POSIX คือมันกำหนด "อินเทอร์เฟซการเขียนโปรแกรมมาตรฐาน" ที่ผู้พัฒนาระบบซอฟต์แวร์และฮาร์ดแวร์ที่ซับซ้อนต้องปฏิบัติตาม ผู้สร้างระบบเหล่านี้ต้องเผชิญกับข้อกำหนดต่างๆ เช่น เวลาในการเข้าสู่ตลาดที่ตึงตัว (เนื่องจากการแข่งขันที่รุนแรง) การลดต้นทุนและการเร่งผลตอบแทนจากการลงทุน ในเวลาเดียวกัน ส่วนแบ่งของค่าใช้จ่ายอันเนื่องมาจากการชะลอตัวในกระบวนการพัฒนานั้นเกิดจากการที่โปรแกรมเมอร์ต้อง "คิดค้นล้อใหม่" ซ้ำแล้วซ้ำอีกในการใช้งานฟังก์ชันที่มีให้ใช้งานมาเป็นเวลานาน แต่สิ่งนี้สามารถหลีกเลี่ยงได้โดย:

• การใช้รหัสซ้ำจากโครงการในอดีตและโครงการคู่ขนาน
• การย้ายรหัสจากระบบปฏิบัติการอื่น
• ดึงดูดนักพัฒนาจากโครงการอื่น ๆ (รวมถึงผู้ที่ใช้ระบบปฏิบัติการอื่น ๆ )

ทั้งหมดนี้เป็นไปได้ด้วยการใช้ระบบปฏิบัติการที่มี API มาตรฐาน ยิ่งไปกว่านั้น หากในกรณีแรก องค์กรต้องมีมาตรฐานภายในที่แน่นอนเพียงพอ (ซึ่งเป็นเรื่องปกติโดยเฉพาะอย่างยิ่งสำหรับระบบปฏิบัติการที่เป็นกรรมสิทธิ์) แล้ว สองกรณีที่สองก็จำเป็นต้องมีมาตรฐานที่ยอมรับโดยทั่วไป เช่น POSIX

ดังนั้น ด้วยการใช้ OS ที่เข้ากันได้กับ POSIX เป็นแพลตฟอร์มสำหรับโครงการของเขา นักพัฒนาจึงได้รับโอกาสในการโอนโค้ดที่เสร็จสิ้นที่ระดับซอร์สโค้ดทั้งจากโครงการในอดีตหรือโครงการคู่ขนานของเขา และจากโครงการของบุคคลที่สาม ซึ่งไม่เพียงแต่ช่วยลดเวลาในการพัฒนาซอฟต์แวร์ได้อย่างมากเท่านั้น แต่ยังช่วยปรับปรุงคุณภาพด้วย เนื่องจากโค้ดที่ทดสอบมีข้อผิดพลาดน้อยกว่าเสมอ

ใครเป็นใครในการพัฒนา POSIX

และเราจะไม่เริ่มต้นด้วยมาตรฐาน POSIX เอง แต่ด้วยการจัดลำดับบทบาทขององค์กรที่เกี่ยวข้องในการทำงาน

ผู้เข้าร่วมคนแรกคือ IEEE(สถาบันวิศวกรไฟฟ้าและอิเล็กทรอนิกส์ สถาบันวิศวกรไฟฟ้าและอิเล็กทรอนิกส์) สมาคมวิชาชีพสาธารณะที่ไม่แสวงหากำไร IEEE มีอายุย้อนไปถึงปี 1884 (อย่างเป็นทางการ - ตั้งแต่ปี 1963) รวมสมาชิก 380,000 คนจาก 150 ประเทศ เผยแพร่วรรณกรรมด้านเทคนิคในส่วนที่สามที่เกี่ยวข้องกับการใช้คอมพิวเตอร์ การควบคุม ไฟฟ้า และเทคโนโลยีสารสนเทศ รวมถึงวารสารมากกว่า 100 ฉบับ เป็นที่นิยมในหมู่มืออาชีพ นอกจากนี้ สมาคมยังจัดการประชุมใหญ่ๆ มากกว่า 300 ครั้งต่อปี IEEE ได้มีส่วนร่วมในการพัฒนามาตรฐานที่มีอยู่มากกว่า 900 มาตรฐาน (www.ieee.ru/ieee.htm) วันนี้สถาบันนี้มีส่วนร่วมในการจัดเตรียม การประสานงาน การอนุมัติ การเผยแพร่มาตรฐาน แต่เนื่องจากสถานะที่เป็นทางการ สถาบันนี้จึงไม่มีอำนาจในการนำเอกสารดังกล่าวเป็นมาตรฐานสากลหรือระดับประเทศ ดังนั้น คำว่า "มาตรฐาน" ในความเข้าใจของ IEEE ควรเข้าใจว่าเป็น "ข้อกำหนด" ซึ่งสอดคล้องกับสถานะของเอกสารที่สมาคมยอมรับมากกว่า ตาม IEEE จะเข้าร่วมในโครงการขององค์กรระหว่างประเทศและระดับภูมิภาคหลายแห่ง - IEC, ISO, ITU (International Telecommunication Union), ETSI (European Telecommunications Standards Institute), CENELEC (European Committee for Electrotechnical Standartization) และในระดับชาติ โปรแกรม ตัวอย่างเช่น ในโปรแกรมขององค์กรเช่น ANSI

IEEE ประกอบด้วย PASC (Portable Application Standards Committee) ซึ่งเป็นคณะกรรมการสมาคมที่พัฒนากลุ่มมาตรฐาน POSIX (www.pasc.org/) PASC เดิมชื่อคณะกรรมการเทคนิคระบบปฏิบัติการ

ผู้เข้าร่วมคนที่สองในการทำงาน - ANSI(สถาบันมาตรฐานแห่งชาติอเมริกัน, สถาบันมาตรฐานแห่งชาติอเมริกัน) - องค์กรเอกชนที่ไม่แสวงหาผลกำไรที่บริหารจัดการและประสานงานในสหรัฐอเมริกาของกิจกรรมมาตรฐาน มีพนักงานเพียง 75 คน แต่ ANSI มีสมาชิก บริษัท องค์กร หน่วยงานราชการ และสถาบันมากกว่า 1,000 ราย (www.ansi.org) ANSI เป็นตัวแทนของสหรัฐอเมริกาในหน่วยงานมาตรฐานสากลที่สำคัญสองแห่งคือ ISO และ IEC

ผู้เข้าร่วมคนที่สาม - ISO(องค์การระหว่างประเทศเพื่อการมาตรฐาน). มันถูกสร้างขึ้นในปี 1946 โดยการตัดสินใจของคณะกรรมการเพื่อการประสานงานมาตรฐานและสมัชชาใหญ่แห่งสหประชาชาติและเริ่มทำงานอย่างเป็นทางการเมื่อวันที่ 23 กุมภาพันธ์ 1947 (www.iso.org) ISO เป็นเครือข่ายของสถาบันมาตรฐานแห่งชาติจาก 146 ประเทศ (หนึ่งประเทศ - สมาชิก ISO หนึ่งราย) โดยมีสำนักเลขาธิการกลางในเจนีวา (สวิตเซอร์แลนด์) มาตรฐาน ISO ได้รับการพัฒนาในคณะกรรมการด้านเทคนิค ซึ่งผลงานแรกคือ Draft International Standard (DIS) ซึ่งหลังจากการอนุมัติหลายครั้ง จะกลายเป็น Final Draft International Standard (FDIS) หลังจากนั้นให้พิจารณาอนุมัติเอกสารฉบับนี้ ถ้าสำเร็จก็จะกลายเป็นมาตรฐานสากล

และในที่สุดก็ - IEC(International Electrotechnical Commission, International Electrotechnical Commission - IEC) ซึ่งก่อตั้งขึ้นในปี 1906 IEC ได้จัดเตรียมและเผยแพร่มาตรฐานสากลสำหรับเทคโนโลยีไฟฟ้า อิเล็กทรอนิกส์ และเทคโนโลยีที่เกี่ยวข้องทั้งหมด (www.iec.ch/) ณ วันที่ 1 พฤศจิกายน พ.ศ. 2547 คณะกรรมการระดับชาติของ 64 ประเทศเป็นสมาชิกของคณะกรรมาธิการนี้ IEC ยังเผยแพร่คำแนะนำซึ่งตีพิมพ์เป็นภาษาอังกฤษและฝรั่งเศสและมีสถานะเป็นมาตรฐานสากล บนพื้นฐานของมาตรฐานระดับภูมิภาคและระดับชาติได้รับการพัฒนา คณะกรรมการด้านเทคนิค (TC) มีหน้าที่รับผิดชอบในการจัดทำมาตรฐานในด้านต่าง ๆ ของกิจกรรม IEC ซึ่งคณะกรรมการระดับชาติที่สนใจในกิจกรรมของ TC นั้นมีส่วนร่วม

IEC เป็นองค์กรสำคัญในการจัดทำมาตรฐานเทคโนโลยีสารสนเทศระดับสากล ในพื้นที่นี้มีคณะกรรมการด้านเทคนิคร่วมด้านเทคโนโลยีสารสนเทศ - JTC 1 ซึ่งก่อตั้งขึ้นในปี 2530 ตามข้อตกลงระหว่าง IEC และ ISO JTC1 มีคณะอนุกรรมการ 17 คณะที่ดูแลทุกอย่างตั้งแต่ซอฟต์แวร์ไปจนถึงภาษาโปรแกรม คอมพิวเตอร์กราฟิกและการแก้ไขภาพ การเชื่อมต่อระหว่างอุปกรณ์ และแนวปฏิบัติด้านความปลอดภัย

การเตรียมมาตรฐาน IEC ใหม่ประกอบด้วยหลายขั้นตอน (เบื้องต้น ระยะข้อเสนอ ระยะเตรียมการ ระยะของคณะกรรมการด้านเทคนิค ระยะคำขอ ระยะอนุมัติ สิ่งพิมพ์) หากเอกสาร IEC มีวัตถุประสงค์เพื่อให้เป็นเพียงข้อกำหนดทางเทคนิคและไม่ใช่มาตรฐานสากล เอกสารฉบับแก้ไขจะถูกส่งไปยังสำนักงานใหญ่เพื่อเผยแพร่ ร่างสุดท้ายของมาตรฐานสากล (FDIS) จะใช้เวลาสี่เดือนจึงจะเสร็จสมบูรณ์ หากได้รับอนุมัติจากสมาชิกคณะกรรมการวิชาการทุกคน จะถูกส่งไปยังสำนักงานกลางเพื่อเผยแพร่โดยไม่มีขั้นตอนการอนุมัติจาก FDIS หลังจากนั้น FDIS จะไปที่คณะกรรมการระดับชาติซึ่งจะต้องอนุมัติภายในสองเดือน FDIS จะถือว่าได้รับการอนุมัติหากคณะกรรมการระดับชาติมากกว่าสองในสามโหวตให้ FDIS และจำนวนคะแนนเสียงเชิงลบไม่เกิน 25% หากเอกสารไม่ผ่านการพิจารณา ให้ส่งแก้ไขให้คณะกรรมการวิชาการและคณะอนุกรรมการแก้ไข มาตรฐานต้องได้รับการเผยแพร่ไม่เกินสองเดือนหลังจากได้รับการอนุมัติจาก FDIS

องค์กรอื่นๆ อีกหลายแห่งมีส่วนร่วมในการพัฒนาและการนำมาตรฐาน POSIX ไปใช้

เปิดกลุ่มเป็นองค์กรระดับสากลสำหรับการกำหนดมาตรฐานซอฟต์แวร์ซึ่งรวมผู้ผลิตและชุมชนผู้ใช้เกือบ 200 รายที่ทำงานในด้านเทคโนโลยีสารสนเทศ (www.opengroup.org/) Open Group ก่อตั้งขึ้นในปี 1995 ผ่านการควบรวมกิจการของสองรุ่นก่อน: X / Open และ Open Software Foundation (OSF) Open Group เชี่ยวชาญด้านการพัฒนาวิธีการรับรองซอฟต์แวร์และการทดสอบการปฏิบัติตามข้อกำหนด โดยเฉพาะอย่างยิ่ง Open Group ให้การรับรองสำหรับพื้นที่ต่างๆ เช่น COE Platform, CORBA, LDAP, Linux Standard Base, Schools Interoperability Framework (SIF), S / MIME Gateway, Single UNIX Specification, Wireless Application Protocol Specifications (WAP) และสุดท้ายคือ POSIX กลุ่มมาตรฐาน (www.opengroup.org/certification/)

กลุ่มแก้ไขมาตรฐานทั่วไปของออสติน (CSRG)- เทคนิคร่วม กลุ่มทำงานก่อตั้งขึ้นในปี 2545 โดย ISO, IEC และ Open Group เพื่อสร้างและบำรุงรักษา เวอร์ชั่นล่าสุดมาตรฐาน 1003.1 ซึ่งจะถูกสร้างขึ้นบนพื้นฐานของ ISO / IEC 9945-1-1996, ISO / IEC 9945-2-1993, IEEE Std 1003.1-1996, IEEE Std 1003.2-1992 และ Single UNIX Specification (www.opengroup.org /press/ 14nov02.htm).

สถาบันมาตรฐานและเทคโนโลยีแห่งชาติ (NIST)- หน่วยงานรัฐบาลกลางในการบริหารเทคโนโลยีของกระทรวงพาณิชย์ (www.nist.gov/public_affairs/general2.htm) ซึ่งก่อตั้งขึ้นในสหรัฐอเมริกาในปี 2444 ภารกิจของ NIST คือการพัฒนาและส่งเสริมมาตรฐานและเทคโนโลยีเพื่อปรับปรุงคุณภาพผลิตภัณฑ์ NIST ประกอบด้วยห้องปฏิบัติการเทคโนโลยีสารสนเทศ (ITL) ซึ่งเป็นหนึ่งในผลลัพธ์ที่ได้คือมาตรฐานการประมวลผลข้อมูลของรัฐบาลกลาง (FIPS, www.opengroup.org/testing/fips/general_info.html) NIST / ITL เสนอชุดการทดสอบเบื้องต้นสำหรับการรับรอง POSIX ภายใต้ FIPS PUB 151-1 1990 ในปี 1991

POSIX คืออะไร?

อย่างเป็นทางการคำว่า POSIXเสนอโดย Richard Stallman เป็นตัวย่อสำหรับ NS ortable อู๋กำลังดำเนินการ NSอินเตอร์เฟส ystem สำหรับ un ทรงเครื่อง(อินเทอร์เฟซระบบปฏิบัติการแบบพกพาสำหรับ Unix) POSIX ได้รับการพัฒนาสำหรับระบบปฏิบัติการที่คล้ายกับ UNIX (เวอร์ชันแรกสุดของพวกเขามีอายุย้อนไปถึงช่วงต้นทศวรรษ 1970) โดยมีเป้าหมายในการจัดหาแหล่งการพกพาไปยังแอปพลิเคชัน

คำอธิบายเบื้องต้นของอินเทอร์เฟซถูกตีพิมพ์ในปี 1986 เมื่อมันถูกเรียกว่า IEEE-IX (เวอร์ชัน UNIX ของ IEEE) อย่างไรก็ตาม ชื่อได้เปลี่ยนไปอย่างรวดเร็ว กลายเป็น POSIX และแล้วในสิ่งพิมพ์ครั้งต่อไป (ย้อนกลับไปในปี 1986) เวอร์ชันใหม่นี้ ใช้มาระยะหนึ่งแล้ว POSIX ถูกเข้าใจว่าเป็นข้อมูลอ้างอิง (หรือคำพ้องความหมาย) ไปยังกลุ่มเอกสารที่เกี่ยวข้อง IEEE 1003.1-1988 และบางส่วนของ ISO / IEC 9945 และเป็นมาตรฐานสากล ISO / IEC 9945.1: 1990 POSIX ที่สมบูรณ์และได้รับการรับรอง นำมาใช้ในปี 1990 ข้อกำหนด POSIX กำหนดกลไกมาตรฐานสำหรับการโต้ตอบระหว่างโปรแกรมแอปพลิเคชันและ OS และปัจจุบันมีมากกว่า 30 มาตรฐานภายใต้การอุปถัมภ์ของ IEEE, ISO, IEC และ ANSI

ตลอดประวัติศาสตร์ของ POSIX POSIX ได้เดินทางมาไกล ด้วยการกำหนดข้อกำหนด เนื้อหาเฉพาะ ขั้นตอน และการขนส่งในการตรวจสอบได้เปลี่ยนแปลงไปหลายครั้ง ตั้งแต่นั้นมา มาตรฐาน POSIX หลายฉบับก็ได้รับการเผยแพร่ภายในองค์กรระหว่างประเทศต่างๆ

ประวัติความเป็นมาของการพัฒนามาตรฐาน POSIX

รุ่นแรกของข้อกำหนด IEEE Std 1003.1 ได้รับการเผยแพร่ในปี 1988 ต่อจากนั้น มีการนำ IEEE Std 1003.1 มาปรับใช้เป็นมาตรฐานสากลหลายฉบับ

ขั้นตอนการพัฒนา POSIX:

ปี 1990

ฉบับที่เผยแพร่ในปี 1988 ได้รับการแก้ไขและกลายเป็นพื้นฐานสำหรับการแก้ไขและเพิ่มเติมเพิ่มเติม ได้รับการรับรองมาตรฐานสากล ISO / IEC 9945-1: 1990

ปี 1993

เผยแพร่รุ่น 1003.1b-1993 แล้ว

ปี 2539

มีการเปลี่ยนแปลง IEEE Std 1003.1b-1993, IEEE Std 1003.1c-1995 และ 1003.1i-1995 แต่เอกสารส่วนใหญ่ยังคงไม่เปลี่ยนแปลง ในปี 1996 การแก้ไข IEEE Std 1003.1 ยังได้รับการอนุมัติให้เป็นมาตรฐานสากล ISO / IEC 9945-1: 1996

ปี 2541

มาตรฐานแรกสำหรับ "เรียลไทม์" ปรากฏขึ้น - IEEE Std 1003.13-1998 เป็นส่วนขยายของมาตรฐาน POSIX สำหรับแอปพลิเคชันฝังตัวแบบเรียลไทม์

ปี 2542

ได้มีการตัดสินใจทำการเปลี่ยนแปลงครั้งสำคัญครั้งแรกในเนื้อหาหลักของมาตรฐานในช่วง 10 ปีที่ผ่านมา ซึ่งรวมถึงการรวมเข้ากับมาตรฐาน 1003.2 (เชลล์และยูทิลิตี้) เนื่องจากเมื่อถึงเวลานั้น มาตรฐานทั้งสองก็แยกจากกัน PASC ตัดสินใจที่จะสรุปการเปลี่ยนแปลงข้อความพื้นฐานหลังจากเสร็จสิ้นการทำงานกับมาตรฐาน IEEE 1003.1a, 1003.1d, 1003.1g, 1003.1j, 1003.1q และ 1003.2b

2547 ร.

ฉบับแก้ไขล่าสุด 1003.1 เผยแพร่เมื่อวันที่ 30 เมษายนและเผยแพร่ภายใต้การอุปถัมภ์ของ Austin Common Standards Revision Group มีการแก้ไขสำหรับมาตรฐานฉบับปี 2544 อย่างเป็นทางการฉบับปี 2547 เป็นที่รู้จักในชื่อ IEEE Std 1003.1, 2004 Edition, The Open Group Technical Standard Base Specifications, ฉบับที่ 6 และรวมถึง IEEE Std 1003.1-2001, IEEE Std 1003.1-2001 / Cor 1-2002 และ IEEE Std 1003.1-2001 / Cor 2-2004

มาตรฐาน POSIX ที่สำคัญที่สุดสำหรับ RT OS

สำหรับระบบปฏิบัติการแบบเรียลไทม์ ข้อกำหนดเจ็ดประการของมาตรฐานมีความสำคัญมากที่สุด (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21) แต่มีเพียงสามรายการเท่านั้นที่ได้รับการสนับสนุนอย่างกว้างขวางในระบบปฏิบัติการเชิงพาณิชย์:

• 1003.1a (คำจำกัดความของระบบปฏิบัติการ)กำหนดอินเทอร์เฟซหลักของระบบปฏิบัติการ การควบคุมงาน สัญญาณ ฟังก์ชันของระบบไฟล์ และทำงานกับอุปกรณ์ กลุ่มผู้ใช้ ไปป์ไลน์ บัฟเฟอร์ FIFO
• 1003.1b (ส่วนขยายเรียลไทม์)อธิบายส่วนขยายแบบเรียลไทม์ เช่น สัญญาณเรียลไทม์ การจัดลำดับความสำคัญ ตัวจับเวลา I / O แบบซิงโครนัสและแบบอะซิงโครนัส สัญญาณ หน่วยความจำที่ใช้ร่วมกัน ข้อความ เริ่มแรก (ก่อนปี 1993) มาตรฐานนี้เรียกว่า POSIX.4
• 1003.1c (กระทู้)กำหนดฟังก์ชันสนับสนุนเธรด - การควบคุมเธรด คุณลักษณะของเธรด mutexes การส่ง แต่เดิมกำหนดให้เป็น POSIX.4a

นอกเหนือจากมาตรฐานเหล่านี้ มาตรฐานต่อไปนี้มีความสำคัญสำหรับ RT OS ซึ่งเป็นส่วนหนึ่งของงานในโครงการ Std 1003.1-2001:

• IEEE 1003.1d-1999.ส่วนขยายเพิ่มเติมแบบเรียลไทม์ เดิมกำหนดเป็น POSIX.4b;
• IEEE 1003.1j-2000.ส่วนขยายแบบเรียลไทม์ที่ได้รับการปรับปรุง (ขั้นสูง)
• IEEE 1003.1q-2000ติดตาม

ขั้นตอนการรับรอง

เพื่อให้เป็นไปตามข้อกำหนด POSIX ระบบปฏิบัติการต้องได้รับการรับรองเทียบกับชุดทดสอบที่เหมาะสม นับตั้งแต่เปิดตัว POSIX ชุดทดสอบได้ผ่านการเปลี่ยนแปลงอย่างเป็นทางการและโดยพฤตินัย

ในปี 1991 NIST ได้พัฒนาโปรแกรมทดสอบ POSIX ภายใต้ FIPS 151-1 (http://standards.ieee.org/regauth/posix/POSIX-A.FM5.pdf) ตัวเลือกการทดสอบนี้อิงตาม IEEE 1003.3 "มาตรฐานสำหรับวิธีทดสอบสำหรับการวัดความสอดคล้องกับ POSIX" ฉบับร่าง 10 วันที่ 3 พฤษภาคม 1989 ในปี 1993 NIST เสร็จสิ้นโปรแกรมการทดสอบ POSIX สำหรับ FIPS 151-1 และเริ่มโปรแกรมสำหรับ FIPS 151 -2 (www.itl.nist.gov/fippubs/fip151-2.htm) FIPS 151-2 ได้ดัดแปลง "เทคโนโลยีสารสนเทศ - อินเทอร์เฟซระบบปฏิบัติการแบบพกพา (POSIX) - ส่วนที่ 1: System Application Program Interface (API)" ซึ่งเป็นมาตรฐาน ISO / IEC 9945-1: 1990 ชุดทดสอบสำหรับ FIPS 151-2 เป็นไปตาม "มาตรฐานสำหรับวิธีทดสอบสำหรับการวัดความสอดคล้องกับ POSIX" ของ IEEE 2003.1-1992

NIST แยกความแตกต่างระหว่างวิธีการรับรองสองวิธี: การรับรองด้วยตนเองและการรับรองโดยห้องปฏิบัติการทดสอบที่ได้รับการรับรองจาก IEEE (Accredited POSIX Testing Laboratories - APTL) ในกรณีแรก บริษัท ดำเนินการทดสอบด้วยตัวเอง แต่ตามแผนที่ได้รับอนุมัติจาก NIST ในกรณีที่สอง การทดสอบดำเนินการโดยห้องปฏิบัติการอิสระโดยใช้ชุดทดสอบอัตโนมัติ โดยรวมแล้ว ห้องปฏิบัติการ APTL สองแห่งได้รับการรับรอง: Mindcraft (www.mindcraft.com) และ Perennial (www.peren.com)

ในปี 1997 NIST / ITL ประกาศความตั้งใจที่จะสิ้นสุดการรับรอง FIPS 151-2 ในสิ้นปีนี้ (อย่างเป็นทางการ 31 ธันวาคม 1997) ในขณะที่ Open Group ประกาศว่ากำลังจะเข้ารับตำแหน่งตั้งแต่วันที่ 1 ตุลาคมของปีนั้น บริการรับรองปีตาม FIPS 151-2 ตามโปรแกรม NIST / ITL ฟังก์ชันเดียวกันนี้ถูกใช้โดย IEEE Standards Association (IEEE-SA) ตั้งแต่วันที่ 1 มกราคม 1998 และอิงตาม FIPS 151-2

ในปี พ.ศ. 2546 IEEE-SA และ Open Group ได้ประกาศโปรแกรมการรับรองร่วมกันใหม่สำหรับ POSIX เวอร์ชันล่าสุด โดยเริ่มด้วย IEEE 1003.1 ™ 2001 ปัจจุบัน Open Group มีชุดทดสอบหลายชุดที่ครอบคลุม IEEE Std 1003.1-1996, IEEE Std 1003.2- 1992, IEEE Std 1003.1-2003 และ IEEE Std 1003.13-1998 (www.opengroup.org/testing/testsuites/posix.html) ผลิตภัณฑ์จะถือว่าผ่านการรับรอง POSIX หากผ่านขั้นตอนการรับรองเต็มรูปแบบ ตามผลการทดสอบที่ตรงตามข้อกำหนดทั้งหมดและถูกป้อนในทะเบียนผลิตภัณฑ์ที่ผ่านการรับรองอย่างเป็นทางการ

ชุดทดสอบประกอบด้วย:

• VSX-PCTS1990 (www.opengroup.org/testing/testsuites/vsxpcts1990.htm) - ชุดการทดสอบความสอดคล้องสำหรับอินเทอร์เฟซระบบ IEEE Std 1003.1-1990;
• VSPSE54 (www.opengroup.org/testing/testsuites/VSPSE54.htm) - ชุดการทดสอบความสอดคล้องสำหรับโปรไฟล์ IEEE Std 1003.13-1998 PSE54 (เรียลไทม์อเนกประสงค์);
• VSX-PCTS2003 (www.opengroup.org/testing/testsuites/vsxpcts2003.htm) - ชุดการทดสอบความสอดคล้องสำหรับอินเทอร์เฟซระบบ IEEE Std 1003.1-2003 (เฉพาะชิ้นส่วนบังคับเท่านั้น);
• VSC-PCTS2003 (www.opengroup.org/testing/testsuites/vscpcts2003.htm) เป็นชุดการทดสอบความสอดคล้องสำหรับ IEEE Std 1003.1-2003 (เชลล์และยูทิลิตี้ - ส่วนบังคับเท่านั้น)

นอกจากนี้ Open Group ยังได้พัฒนาเกณฑ์มาตรฐานสำหรับ POSIX Realtime Standards และ Embedded POSIX Standards Profile ชุดทดสอบ POSIX Realtime (www.opengroup.org/testing/testsuites/realtime.html) ประกอบด้วยการทดสอบต่อไปนี้:

• IEEE POSIX 1003.1b-1993 / 1003.1i-1995 ส่วนขยายเรียลไทม์และ IEEE POSIX 1003.1,2003 Edition;
• ส่วนขยาย IEEE Std POSIX 1003.1c-1995 (pthreads) และ IEEE POSIX 1003.1,2003 Edition;
• IEEE POSIX 1003.1d-1999 ส่วนขยายเรียลไทม์เพิ่มเติมและ IEEE POSIX 1003.1,2003 Edition;
• IEEE POSIX 1003.1j-2000 Advanced Realtime Extension และ IEEE POSIX 1003.1,2003 Edition;
• IEEE POSIX 1003.1q-2000 Trace และ IEEE POSIX 1003.1,2003 Edition และ IEEE POSIX 1003.1,2003 Edition;

ชุดทดสอบโปรไฟล์มาตรฐาน POSIX แบบฝัง (www.opengroup.org/testing/testsuites/embedded.html) ประกอบด้วยการทดสอบต่อไปนี้:

• IEEE POSIX 1003.1-1990 (5310 การทดสอบ);
• IEEE POSIX 1003.1b-1993 / 1003.1i-1995 ส่วนขยายเรียลไทม์ (การทดสอบ 1430);
• IEEE Std POSIX 1003.1c-1995 ส่วนขยายเธรด (pthreads) (การทดสอบ 1232);
• โปรไฟล์ IEEE POSIX 1003.13-1998 52

เล็กน้อยเกี่ยวกับความสับสนในคำศัพท์

ในความสัมพันธ์กับกลุ่มมาตรฐาน POSIX ภาษาอังกฤษมักไม่ใช้คำเดียว แต่มีมากถึงสามคำ น่าเสียดายที่ความหมายคล้ายกันและมักถูกแปลในลักษณะเดียวกัน ซึ่งทำให้เกิดความสับสน ข้อกำหนดเหล่านี้มีดังนี้:

• ความเข้ากันได้ (ตามตัวอักษร - "ความเข้ากันได้");
• การปฏิบัติตาม (ตัวอักษร - "การปฏิบัติตาม");
• สอดคล้อง (ตัวอักษร - "สอดคล้อง")

เทอมแรกที่ใช้กับ POSIX ไม่ได้กำหนดไว้อย่างเป็นทางการ ประการที่สองหมายความว่าองค์กร - ผู้ผลิตผลิตภัณฑ์ซอฟต์แวร์ประกาศอย่างอิสระว่าผลิตภัณฑ์นี้ (ทั้งหมดหรือบางส่วน) เป็นไปตามมาตรฐาน NIST-PCTS ที่ระบุไว้ เทอมที่สามหมายความว่า ซอฟต์แวร์ผ่านระบบการทดสอบที่จัดตั้งขึ้นด้วยความช่วยเหลือของห้องปฏิบัติการที่ได้รับการรับรองหรือภายใน Open Group และมีเอกสารหลักฐานสำหรับสิ่งนี้ (ที่เรียกว่าคำชี้แจงความสอดคล้อง) นอกจากนี้ในเนื้อความของบทความ จะมีการอ้างถึงต้นฉบับของคำศัพท์ทุกแห่งเพื่อขจัดความกำกวม

OS RV . ที่ผ่านการรับรอง

หากคุณปฏิบัติตามกฎเกณฑ์ที่เข้มงวดซึ่งกำหนดให้มีการเผยแพร่ข้อมูลบน RT OS ที่ผ่านการรับรองในการลงทะเบียนอย่างเป็นทางการและดำเนินการทดสอบในระดับความสอดคล้อง ในปัจจุบันมีเพียง RT OS ที่ผ่านการรับรองเพียงสองรายการเท่านั้น (ข้อมูลเรียงตามลำดับเวลา):

LynxOS v.3(ผลิตภัณฑ์ของ Lynx Real-Time Systems ซึ่งปัจจุบันเรียกว่า LynuxWorks, Inc., www.lynuxworks.com) ได้รับการออกแบบมาเพื่อพัฒนาซอฟต์แวร์สำหรับระบบฝังตัวที่ทำงานแบบเรียลไทม์ ผู้ผลิต OEM และอุปกรณ์โทรคมนาคม โดยเฉพาะผู้ผลิตระบบออนบอร์ด สำหรับการใช้งานทางทหาร ... การพัฒนาสามารถทำได้ทั้งบนระบบเป้าหมายเอง (โฮสต์เอง) และบนคอมพิวเตอร์เครื่องมือ (โฮสต์) ซอฟต์แวร์สำเร็จรูปได้รับการออกแบบให้ทำงานบนระบบเป้าหมาย (เป้าหมาย) LynxOS v.3 ได้รับการรับรองตามมาตรฐาน POSIX บนแพลตฟอร์ม Intel และ PowerPC ข้อมูลนี้สามารถพบได้บนเว็บไซต์ IEEE ที่ http://standards.ieee.org/regauth/posix/posix2.html LynxOS ได้รับการรับรอง POSIX 1003.1-1996 โดย Mindcraft ซึ่งเป็นห้องปฏิบัติการทดสอบ POSIX ที่ได้รับการรับรอง IEEE POSIX บนชุดทดสอบความสอดคล้อง NIST FIPS 151-2 หมายเลขเอกสารการรับรอง: ไฟล์อ้างอิง: IP-2LYX002, ไฟล์อ้างอิง: IP-2LYX001.

ความซื่อสัตย์ v.5(ผลิตภัณฑ์ของ Green Hills Software, www.ghs.com) ได้รับการรับรองว่าสอดคล้องกับ POSIX 1003.1-2003, System Interfaces for PowerPC architecture ในเดือนกรกฎาคม พ.ศ. 2547 (http://get.posixcertified.ieee.org/select_product. tpl) ชุดทดสอบ VSX-PCTS 2003

POSIX และระบบปฏิบัติการ QNX

QNX v.4.20 (พัฒนาโดย QNX Software Systems, www.qnx.com) เป็นไปตามข้อกำหนด POSIX 1003.1-1988 สำหรับแพลตฟอร์ม Intel โดย DataFocus Incorporated ดำเนินการทดสอบเมื่อวันที่ 13 กันยายน 2536 และเผยแพร่เมื่อวันที่ 1 พฤศจิกายน 2536 NIST PCTS 151-1 Test Suite เวอร์ชัน 1.1

QNX Neutrino (เวอร์ชัน 6.3) เป็นไปตามมาตรฐานตระกูล POSIX ต่อไปนี้ (www.qnx.com/download/download/8660/portability.pdf):

• POSIX.1 (IEEE 1003.1);
• POSIX.1a (IEEE 1003.1a);
• POSIX.2 (IEEE 1003.2);
• POSIX.4 (IEEE 1003.1b);
• POSIX.4a (IEEE 1003.1c);
• POSIX.1b (IEEE 1003.1d), IEEE 1003.1j;
• POSIX.12 (IEEE 1003.1g)

QNX Software Systems ผู้สร้าง QNX Neutrino กำลังวางแผน QNX Neutrino ให้สอดคล้องกับมาตรฐานเหล่านี้ มีการวางแผนงานสำหรับปี 2548 (www.qnx.com/news/pr_959_1.html)

วรรณกรรม

1. คู่มือการใช้งานสมาคมมาตรฐาน IEEE IEEE ตุลาคม 2547
2. เควิน เอ็ม. โอบแลนด์. POSIX ในแบบเรียลไทม์, การเขียนโปรแกรมระบบสมองกลฝังตัว, 2001.
3. มาตรฐาน IEEE / ANSI 1003.1: เทคโนโลยีสารสนเทศ - (POSIX) - ส่วนที่ 1: แอปพลิเคชันระบบ: Program Interface (API)
4. แกลไมสเตอร์, บี.โอ. การเขียนโปรแกรมสำหรับโลกแห่งความจริง POSIX.4เซบาสโตโพล์ แคลิฟอร์เนีย: O'Reilly & Associates, 1995
5. สถาบันมาตรฐานและเทคโนโลยีแห่งชาติ PCTS: 151-2, POSIX Test Suite
6. POSIX: รับรองโดย IEEE และ The Open Groupนโยบายที่ผ่านการรับรอง The Open Group, 21 ตุลาคม 2546, แก้ไข 1.1.

Alexey Fedorchuk
ปี 2548

หนึ่งในคุณสมบัติที่โดดเด่นของโครงสร้างเชิงตรรกะของระบบไฟล์ของระบบปฏิบัติการตระกูล POSIX คือการจัดระเบียบแบบลำดับชั้นหรือแบบต้นไม้ (แต่อย่างที่ฉันพูด ต้นไม้ดูแปลกไปเล็กน้อย) นั่นคือเช่นเดียวกับใน DOS หรือ Windows ใด ๆ ไม่มีการกำหนด (เช่น ตัวอักษรหรืออื่น ๆ ) สำหรับสื่อแต่ละรายการและพาร์ติชั่น: ทั้งหมดนี้รวมอยู่ในโครงสร้างเดียวเป็นไดเร็กทอรีย่อยของไดเร็กทอรีหลัก เรียกว่าราก กระบวนการเชื่อมต่อ ระบบไฟล์บนสื่อฟิสิคัลอิสระ (และพาร์ติชั่นของพวกมัน) ไปยังรูทของโครงสร้างไฟล์เรียกว่าเมานต์ และไดเร็กทอรีย่อยที่พวกมันมีอยู่จะเรียกว่าจุดเชื่อมต่อ

ในอดีต Unix ได้พัฒนาโครงสร้างไดเร็กทอรีที่เฉพาะเจาะจงซึ่งมีความคล้ายคลึงกันมากในตระกูลในแง่ของทั่วไป แต่มีรายละเอียดแตกต่างกันเล็กน้อย โดยเฉพาะอย่างยิ่ง ลำดับชั้นของไฟล์บนระบบ BSD เกือบจะเหมือนกัน แต่แตกต่างจากบน Linux และในระยะหลังจะพบความแตกต่างที่สำคัญระหว่างการแจกแจงที่แตกต่างกัน ขึ้นอยู่กับข้อเท็จจริงที่ว่าโครงสร้างของลำดับชั้นของไฟล์เป็นหนึ่งในคุณลักษณะเฉพาะของการแจกจ่าย

สถานการณ์นี้ทำให้เขียนแอปพลิเคชันข้ามแพลตฟอร์มได้ยาก ดังนั้นจึงมีและกำลังพัฒนาโครงการเพื่อสร้างมาตรฐานลำดับชั้นของไฟล์ - FHS (Filesystem Hierarchy Standard)

โปรเจ็กต์ FHS มีจุดมุ่งหมายหลักในการปรับปรุงโครงสร้างไดเร็กทอรีในลีนุกซ์รุ่นต่างๆ ต่อมาได้มีการดัดแปลงเพื่อผู้อื่น ระบบคล้ายยูนิกซ์(รวมถึงกลุ่ม BSD) และขณะนี้มีความพยายาม (แต่ไม่ประสบความสำเร็จมาก) ในการทำให้เป็นระบบมาตรฐานสำหรับระบบ POSIX ไม่ใช่แค่ในชื่อเท่านั้น แต่ในความเป็นจริงด้วย

มาตรฐาน FHS ตั้งอยู่บนหลักการพื้นฐานสองประการ - การแยกที่ชัดเจนในลำดับชั้นของไฟล์ของไดเร็กทอรีที่แชร์และไม่แชร์ ในด้านหนึ่ง และไม่เปลี่ยนรูปแบบและเปลี่ยนแปลงไม่ได้ในอีกด้านหนึ่ง

ความแตกต่างระหว่างไดเร็กทอรีที่ใช้ร่วมกันและไดเร็กทอรีที่ไม่แบ่งใช้เกิดจากลักษณะเครือข่ายโดยธรรมชาติของ Unix กล่าวคือ ข้อมูลที่เกี่ยวข้องกับเครื่องโลคัล (เช่น ไฟล์การกำหนดค่าสำหรับอุปกรณ์) ควรอยู่ในไดเร็กทอรีแยกจากที่มีเนื้อหาจากเครื่องอื่นบนเครือข่าย โลคัลหรือโกลบอล (ตัวอย่างที่ไม่ใช่แค่ผู้ใช้ data แต่ยังรวมถึงโปรแกรม) ...

สาระสำคัญของความขัดแย้งระหว่างไดเร็กทอรีที่ไม่เปลี่ยนรูปและที่ไม่เปลี่ยนได้นั้นง่ายต่อการอธิบายด้วยตัวอย่าง ดังนั้นโปรแกรมผู้ใช้ทั่วไปที่เหมือนกันโดยธรรมชาติแล้วควรจะไม่เปลี่ยนรูปแบบ (หรือมากกว่านั้น มีให้สำหรับการแก้ไขเฉพาะผู้ดูแลระบบเท่านั้น แต่ไม่ใช่สำหรับผู้ใช้เองที่ใช้งานพวกเขาในงานของเขา) ในเวลาเดียวกัน โปรแกรมเหล่านี้ระหว่างทำงาน ไม่เพียงแต่สร้างไฟล์ข้อมูล เช่น ข้อความหรือรูปภาพ (ลักษณะตัวแปรจะชัดเจนโดยไม่มีความคิดเห็น) แต่ข้อมูลบริการทุกประเภท เช่น ไฟล์บันทึก ไฟล์ชั่วคราว และอื่นๆ . ซึ่งควรจัดกลุ่มเป็นไดเร็กทอรีแยกจากไฟล์โปรแกรมเรียกทำงานจริงที่จำเป็นในการรัน ไลบรารี ไฟล์คอนฟิกูเรชัน ฯลฯ

อย่างไรก็ตาม แม้จะมีการส่งเสริมอย่างแข็งขันในลีนุกซ์รุ่นต่างๆ จากรุ่นทั่วไป แต่ FHS ก็ยังไม่ได้รับสถานะของมาตรฐานที่แท้จริง มีลีนุกซ์ดิสทริบิวชั่นค่อนข้างน้อยที่ไม่ได้ใช้บทบัญญัติบางประการ และมีความสัมพันธ์เพียงบางส่วนกับลำดับชั้นไฟล์ดั้งเดิมของระบบ BSD

และเหตุผลก็คือ FHS เพิกเฉยต่อความขัดแย้งอีกประการหนึ่ง ซึ่งสำคัญมากสำหรับผู้ใช้: การต่อต้านของชิ้นส่วนที่กู้คืนได้ง่ายของระบบไฟล์ และองค์ประกอบที่กู้คืนได้ยากหรือไม่สามารถกู้คืนได้เลย

สิ่งแรกที่น่าแปลกก็คือสามารถนำมาประกอบกับระบบฐานได้: การติดตั้งใหม่จากสื่อการกระจายในกรณีที่เกิดความผิดพลาดร้ายแรงไม่ใช่เรื่องยาก เห็นได้ชัดว่าส่วนที่ยากต่อการกู้คืนของระบบไฟล์นั้นรวมถึงข้อมูลผู้ใช้ด้วย แม้ว่าจะได้รับการสำรองข้อมูลอย่างสม่ำเสมอ (และจำนวนผู้ใช้ที่ระมัดระวังมากเพียงใด) การปรับใช้จากไฟล์เก็บถาวรจะใช้เวลามาก (และแทบจะหลีกเลี่ยงไม่ได้ ขาดทุนบ้าง)

นอกจากนี้ ในระบบ BSD และการกระจาย Linux ตามแหล่งที่มา ฉันจะจัดประเภททุกอย่างที่เกี่ยวข้องกับการจัดการแพ็คเกจเป็นไดเรกทอรีที่กู้คืนได้ยาก - แผนผังพอร์ต FreeBSD หรือ pkgsrc ใน NetBSD (และระบบที่ยืมมา) ของคู่กันในการแจกแจง Linux ซอร์สโค้ดจริงของโปรแกรมที่พอร์ต และซอร์สโค้ดของระบบด้วย สำหรับแม้ว่าทั้งหมดนี้อยู่ในชุดการแจกจ่าย ตามกฎแล้วส่วนประกอบเหล่านี้ของระบบไฟล์จะได้รับการอัปเดตโดยผู้ใช้โดยการซิงโครไนซ์กับเซิร์ฟเวอร์โครงการผ่านเครือข่าย (มิฉะนั้นการใช้งานจะไม่มีความหมาย) และการสูญเสียของพวกเขาจะนำมาซึ่งความสูญเสียทั้งชั่วคราว (โดยเฉพาะอย่างยิ่งกับการเชื่อมต่อโมเด็ม) และการสูญเสียทางการเงิน (มีเพียงไม่กี่คนที่เป็นเจ้าของที่มีความสุขในการเข้าถึงอินเทอร์เน็ตฟรี)

การยึดมั่นอย่างเคร่งครัดกับแนวคิดของการแยกไดเร็กทอรีที่แชร์และไม่แชร์, ไม่เปลี่ยนรูปและไม่เปลี่ยนรูป, กู้คืนได้และไม่สามารถกู้คืนจากไดเร็กทอรีอื่น ๆ ช่วยให้สามารถแยกสาขาออกจากกันภายในลำดับชั้นไฟล์ที่เหมือนต้นไม้เดียว - นั่นคือในรูปแบบ ของระบบไฟล์อิสระที่อยู่ในอุปกรณ์แยก (ดิสก์ ส่วนดิสก์ สไลซ์ พาร์ติชั่น ฯลฯ) มีเหตุผลหลายประการ - ทั้งการเพิ่มประสิทธิภาพและความน่าเชื่อถือที่เพิ่มขึ้น และการพิจารณาถึงความสะดวกเพียงอย่างเดียว - แต่เราจะไม่พูดถึงพวกเขาในตอนนี้ เพราะใน ช่วงเวลานี้สิ่งที่สำคัญสำหรับเราคือสาขาของโครงสร้างไฟล์เหล่านี้ต้องรวมอยู่ในระบบไฟล์ทั่วไป

ชุดไดเร็กทอรีระบบ POSIX ทั่วไป

ตามความเป็นจริงแล้วสำหรับการทำงานจำเป็นต้องมีระบบไฟล์เพียงระบบเดียว - ระบบที่ติดตั้งในไดเร็กทอรีรากของแผนผังไฟล์ (อะนาล็อกของต้นไม้โลก Yggdrassil) ไดเร็กทอรีรากและกิ่งก้านที่ขาดไม่ได้จะต้องประกอบด้วยระบบไฟล์เดียวที่อยู่บนสื่อเดียว - ดิสก์ พาร์ติชั่นดิสก์ อาร์เรย์ RAID ของซอฟต์แวร์หรือฮาร์ดแวร์ หรือโลจิคัลวอลุ่มในการทำความเข้าใจ LVM และควรมีส่วนประกอบทั้งหมดที่จำเป็นในการเริ่มต้นระบบและไม่มีอะไรมากไปกว่านั้น

คุณสามารถดูองค์ประกอบของไดเรกทอรีรากด้วยคำสั่ง

$ ls -1 /

ซึ่งในระบบ POSIX ใด ๆ จะแสดงชุดไดเร็กทอรีของสุภาพบุรุษน้อยที่สุด:

ถังขยะ / boot / etc / root / sbin /

มันอยู่ในนั้นที่รวบรวมไฟล์ทั้งหมดโดยที่ระบบไม่สามารถมีอยู่ได้ ไดเร็กทอรีอื่นมีลักษณะดังนี้:

หน้าแรก / mnt / opt / tmp / usr / var /

a) ไม่จำเป็น (อย่างน้อยก็ในทางทฤษฎี - เป็นเรื่องยากที่จะทำโดยปราศจากพวกเขา) b) ไม่ใช่ทุกคนที่มีอยู่ในระบบและการแจกแจงทั้งหมดและ c) แต่ละรายการสามารถเป็นได้ (และมักจะเป็น - หากคุณทำทุกอย่างตามที่คุณคิด ) จุดเชื่อมต่อของสาขาของตัวเองของแผนผังไฟล์

นอกจากนี้ ในกรณีส่วนใหญ่ มีไดเร็กทอรีย่อยอีกสองไดเร็กทอรีในรูทของระบบไฟล์ของ OS ที่เข้ากันได้กับ POSIX:

กำลังพัฒนา / proc /

สิ่งเหล่านี้มักจะเป็นจุดเชื่อมต่อของระบบไฟล์เสมือน - อุปกรณ์และกระบวนการ ตามลำดับ (แม้ว่าถ้าระบบไฟล์ของอุปกรณ์ไม่ได้ใช้ ไดเร็กทอรี / dev จะต้องเป็นส่วนประกอบของระบบไฟล์รูท สุดท้ายบนระบบ Linux เช่น กฎ รูทของโครงสร้างไฟล์คือและไดเร็กทอรี / lib สำหรับไลบรารีระบบหลัก และด้วย udev ไดเร็กทอรี / sys ที่หลีกเลี่ยงไม่ได้คือตำแหน่งที่ระบบไฟล์เสมือน sysfs ถูกเมาต์ด้วย

ระบบไฟล์รูท

ระบบไฟล์รูทไม่สามารถแชร์ได้ (กล่าวคือ ไม่ได้ตั้งใจให้แชร์โดยเครื่องอื่นบนเครือข่าย) และไม่สามารถเปลี่ยนแปลงได้ (กล่าวคือ เฉพาะผู้ดูแลระบบเท่านั้นที่สามารถทำการเปลี่ยนแปลงได้ แต่ไม่ใช่โปรแกรมผู้ใช้ และยิ่งไปกว่านั้น ไม่ใช่ผู้ใช้) นอกจากนี้ เราไม่แนะนำให้สร้างไดเร็กทอรีย่อยในส่วนที่เกินจากมาตรฐานที่ให้ไว้ (และระบุไว้ข้างต้น)

เลือกการเติมระบบไฟล์รูทเพื่อให้เครื่องสามารถเริ่มต้นและคงฟังก์ชันการทำงานที่น้อยที่สุดไว้ได้แม้ในระหว่างการบู๊ตฉุกเฉิน (หรือในโหมดผู้ใช้คนเดียว) เมื่อไม่ได้ติดตั้งระบบไฟล์อื่นๆ ทั้งหมด (และตามลำดับ เช่น / usr หรือ / var อาจไม่สามารถใช้ได้

ดังนั้นการเริ่มต้นเครื่องจึงมาจากไฟล์ไดเร็กทอรี / boot และ / etc. ไฟล์แรกมีเคอร์เนลของระบบ — ไฟล์ปฏิบัติการ "วัตถุประสงค์พิเศษ" — และทั้งหมดที่จำเป็นในการโหลด — บน Linux เช่น แผนที่ระบบ (/etc/System.map) และบน FreeBSD — เคอร์เนลที่โหลดได้ โมดูล อย่างไรก็ตาม บางครั้งเคอร์เนลจะอยู่ที่รูทของระบบไฟล์โดยตรง จากนั้นไดเร็กทอรี / boot อาจหายไปทั้งหมด และไดเร็กทอรี / modules อาจถูกสงวนไว้สำหรับเคอร์เนลโมดูล

ไดเร็กทอรี / etc ใช้สำหรับไฟล์คอนฟิกูเรชันทั้งระบบที่กำหนดเงื่อนไขในการโหลด เนื้อหาของมันขึ้นอยู่กับระบบเป็นอย่างมาก (และใน Linux - รวมถึงชุดการแจกจ่ายด้วย) ดังนั้นฉันจะไม่พิจารณาที่นี่ - ฉันจะต้องกลับไปที่หัวข้อนี้มากกว่าหนึ่งครั้ง

ฟังก์ชั่นที่จำเป็นขั้นต่ำนั้นมาจากเนื้อหาของไดเร็กทอรี / bin และ / sbin - ประกอบด้วยไฟล์ปฏิบัติการของผู้ใช้ที่สำคัญที่สุดและโปรแกรมระบบตามลำดับซึ่งจะช่วยให้คุณดำเนินการซ่อมแซมและช่วยเหลือที่ซับซ้อนและ นำรถกลับร่างมนุษย์หลังจากความล้มเหลว

การแบ่งระบบและโปรแกรมผู้ใช้ออกเป็นไดเร็กทอรีย่อยของรูทนั้นค่อนข้างจะเป็นไปตามอำเภอใจ คำสั่งเหล่านี้ไม่ได้มีไว้สำหรับการแก้ปัญหาของผู้ใช้จริงๆ มีเพียงไดเร็กทอรี / bin ที่มีคำสั่งการดูแลระบบ ซึ่งผู้ใช้ทั่วไปจะเข้าถึง (หรือสามารถเข้าถึงได้) เป็นครั้งคราว และไดเร็กทอรี sbin มีไว้สำหรับคำสั่งที่ผู้ใช้ไม่ควรทราบ และในกรณีส่วนใหญ่ เขาจะยังไม่สามารถใช้งานได้เนื่องจากไม่มีอำนาจที่เหมาะสม (เช่น สิทธิ์ในการเข้าถึงไฟล์อุปกรณ์ที่จำเป็น)

ในการรันโปรแกรม POSIX (รวมถึงโปรแกรมที่คอมไพล์ในไดเร็กทอรี / bin และ sbin) ตามกฎแล้ว คุณต้องเข้าถึงฟังก์ชันของไลบรารีทั้งระบบ (โดยหลักคือไลบรารี glibc หลัก) ดังนั้นองค์ประกอบที่ขาดไม่ได้ (เกือบ) ของไดเร็กทอรีรูทคือไดเร็กทอรีย่อย / lib ซึ่งประกอบเข้าด้วยกัน

บน Linux ไดเร็กทอรี / lib มีจุดประสงค์ที่สำคัญอีกอย่างหนึ่ง — ไดเร็กทอรีย่อย (/ lib / โมดูล) มีโมดูลเคอร์เนลที่โหลดได้ (บน FreeBSD ตำแหน่งคือ / boot / kernel)

ใน FreeBSD ไม่พบไดเร็กทอรี / lib บนระบบไฟล์รูท - ส่วนประกอบที่เกี่ยวข้องจะอยู่ที่นี่ใน / usr / lib (ดูด้านล่าง) เนื่องจากในอดีต FreeBSD ได้สร้างโปรแกรมหลักทั่วทั้งระบบ เพื่อให้ฟังก์ชันไลบรารีที่พวกเขาต้องการฝังอยู่ในไฟล์สั่งการ (เรียกว่า การเชื่อมโยงแบบสแตติก ซึ่งจะกล่าวถึงในบทที่ 14) ในโปรแกรมสาขาที่ 5 ของ FreeBSD จากไดเร็กทอรี / bin และ / sbin นั้นเชื่อมโยงกันแบบไดนามิก นั่นคือในกรณีที่ไม่มีไดเร็กทอรี / usr (และใน Free จะเป็นการแยกสาขาของระบบไฟล์เกือบทุกครั้ง) พวกมันจะไม่ทำงาน เพื่อชดเชยสิ่งนี้ มีไดเร็กทอรี / restore ที่เกินมาตรฐานซึ่งมีโปรแกรมเดียวกัน แต่มีการเชื่อมโยงแบบสแตติก

ในที่สุด / รูท นี่คือโฮมไดเร็กทอรีปกติของผู้ใช้ที่มีชื่อเดียวกัน นั่นคือผู้ดูแลระบบ เนื่องจากไม่ได้ใช้งานจริง (หรืออย่างน้อยก็ไม่ควรทำ) เนื้อหาจึงเป็นเพียงไฟล์การกำหนดค่าของ superuser เอง (เชลล์คำสั่งของผู้ใช้ ตัวแก้ไขรายการโปรด และอื่นๆ)

สาขา / usr

ในอดีต ไดเร็กทอรี / usr มีไว้สำหรับโปรแกรมและข้อมูลของผู้ใช้ ฟังก์ชั่นเหล่านี้ถูกแยกระหว่าง / usr / local และ / home (แม้ว่าตอนนี้จะเป็นลิงก์สัญลักษณ์ไปยัง / usr / home โดยค่าเริ่มต้นใน FreeBSD) ไดเร็กทอรี / usr - ไม่สามารถเปลี่ยนแปลงได้ แต่ใช้ร่วมกัน - ทำหน้าที่เป็นที่เก็บสำหรับโปรแกรมแอปพลิเคชันจำนวนมากและทุกอย่างที่เกี่ยวข้อง - ซอร์สโค้ด ไฟล์การกำหนดค่า ไลบรารีที่แบ่งใช้ เอกสารประกอบ และอื่นๆ

องค์ประกอบของไดเร็กทอรี / usr แตกต่างกันอย่างมากระหว่างระบบ BSD และ Linux ในอดีตจะมีเพียงส่วนสำคัญของระบบปฏิบัติการ (สิ่งที่ใน FreeBSD ถูกรวมเป็นหนึ่งโดยแนวคิดของการแจกแจง) แอปพลิเคชั่นที่ติดตั้งจากพอร์ตหรือแพ็คเกจมีตำแหน่งในไดเร็กทอรีย่อย / usr / local ซึ่งสามารถแสดงสาขาที่แยกจากกันของโครงสร้างไฟล์

ใน Linux ไดเร็กทอรี / usr ทำหน้าที่เป็นที่เก็บสำหรับโปรแกรมทั้งหมด (และส่วนประกอบ) ที่รวมอยู่ในชุดการแจกจ่าย และไดเรกทอรีย่อย / usr / local มักมีไว้สำหรับโปรแกรมที่รวบรวมจากแหล่งที่มาอย่างอิสระ

ไม่ว่าในกรณีใด องค์ประกอบปกติของไดเร็กทอรี / usr จะเป็นดังนี้ (ตามที่รายงานโดยคำสั่ง ls -1):

X11R6 / bin / ฯลฯ / รวม / lib / libexec / local / sbin / share / src /

ดังที่ได้กล่าวไปแล้วไดเร็กทอรีย่อย / usr / local เป็นสาขาที่แยกจากกันของโครงสร้างไฟล์ ดังนั้นจะถูกพิจารณาแยกกัน วัตถุประสงค์ของไดเร็กทอรีอื่นมีดังนี้:

• / usr / bin และ / usr / sbin มีไว้สำหรับไฟล์ปฏิบัติการของผู้ใช้และโปรแกรมระบบ (ในที่นี้เส้นขอบระหว่างกันนั้นยิ่งโดยพลการมากกว่าในกรณีของไดเร็กทอรีรูท) จุดประสงค์ที่นอกเหนือไปจากการตรวจสอบการทำงานพื้นฐานของ ระบบ;
• / usr / etc ใช้สำหรับไฟล์การกำหนดค่าแอปพลิเคชันแต่ละรายการ
• / usr / include มีไฟล์ส่วนหัวที่เรียกว่าที่จำเป็นสำหรับการเชื่อมโยง ไฟล์ปฏิบัติการด้วยองค์ประกอบห้องสมุด
• / usr / lib และ / usr / libexec เป็นไดเร็กทอรีสำหรับไลบรารีที่แบ่งใช้ซึ่งแอพพลิเคชันของผู้ใช้ขึ้นอยู่กับ;
• / usr / share - พื้นที่เก็บข้อมูลที่มีความหลากหลายมากที่สุดที่เรียกว่า ส่วนประกอบที่เป็นอิสระทางสถาปัตยกรรม: ที่นี่ คุณสามารถดูเอกสารในรูปแบบต่างๆ และตัวอย่างของไฟล์การกำหนดค่า และข้อมูลที่ใช้โดยโปรแกรมการจัดการคอนโซล (แบบอักษร เค้าโครงแป้นพิมพ์) และคำอธิบายของเขตเวลา
• / usr / src - ไดเรกทอรีซอร์สโค้ด; ใน Linux ปกติจะวางเฉพาะซอร์สโค้ดของเคอร์เนล (เคอร์เนล) ของระบบที่นี่ ในโคลน BSD ซึ่งเป็นชุดซอร์สโค้ดที่สมบูรณ์ของความซับซ้อน ซึ่งใน FreeBSD เรียกว่าการแจกแจง ตามกฎแล้วไม่ควรวางแหล่งที่มาของโปรแกรมที่ประกอบขึ้นเองที่นี่
• / usr / X11R6 - ไดเร็กทอรีสำหรับส่วนประกอบระบบหน้าต่าง X - ไฟล์ปฏิบัติการ (/ usr / X11R6 / bin), ไลบรารี (/ usr / X11R6 / lib), ส่วนหัว (/ usr / X11R6 / รวม), เอกสารประกอบ (/ usr / X11R6 / ชาย); ไฟล์แอปพลิเคชัน X ไม่ควรวางที่นี่ (ยกเว้นบางทีสำหรับตัวจัดการหน้าต่าง) - ตำแหน่งของพวกเขาอยู่ใน / usr, / usr / local หรือ / opt ขึ้นอยู่กับระบบ

นอกจากนี้ ไดเร็กทอรี / usr อาจมีไดเร็กทอรีย่อย / usr / var และ / usr / tmp ซึ่งมักจะเป็นลิงก์สัญลักษณ์ไปยังสาขาที่เกี่ยวข้องของไดเร็กทอรีรูท และในลีนุกซ์รุ่นบางรุ่น เอกสารคู่มือทั้งระบบหลัก, หน้าคน (ในไดเร็กทอรีย่อย / usr / man) จะถูกวางโดยตรงใน / usr

สุดท้าย บนระบบ BSD และการกระจาย Linux แบบอิงแหล่งที่มา (เช่น Gentoo) ไดเร็กทอรี / usr จะมีไดเร็กทอรีย่อยสำหรับระบบการจัดการแพ็คเกจ - พอร์ต FreeBSD และ OpenBSD (/ usr / พอร์ต) ที่เหมือนกันบนระบบอื่น (/ usr / portage ใน Gentoo) แม้ว่าจากมุมมองของการปฏิบัติตามตัวอักษรและจิตวิญญาณของมาตรฐาน FHS (ตัวเขาเองไม่ได้พูดถึงพอร์ตและระบบที่คล้ายกัน) ที่ที่เหมาะสมกว่าสำหรับพวกเขาคือไดเร็กทอรี / var (ดูด้านล่าง) - และ นี่คือสิ่งที่ทำในการแจกแจงเช่น CRUX และ Archlinux

สาขา / usr / local

ดังที่ได้กล่าวไปแล้ว / usr / local branch ใน Linux นั้นมีไว้สำหรับโปรแกรมที่คอมไพล์เองจากแหล่งที่มา (ไม่รวมอยู่ในชุดการแจกจ่ายนี้) และบน FreeBSD มันทำหน้าที่เป็นพื้นที่เก็บข้อมูลสำหรับแอปพลิเคชันส่วนใหญ่ของผู้ใช้ — เกือบทุกอย่างที่อยู่นอกการแจกจ่ายและติดตั้งจากแพ็คเกจหรือพอร์ต ดังนั้น โครงสร้างไดเร็กทอรีโดยรวมจึงเป็นไปตามของสาขา / usr (โดยมีข้อยกเว้นที่เข้าใจได้):

ถังขยะ / etc / รวม / lib / man / sbin / share /

เนื้อหาของไดเรกทอรีย่อยก็คล้ายกัน: โปรแกรมปฏิบัติการ (/ usr / local / bin และ / usr / local / sbin), configs (/ usr / local / ฯลฯ ) ไลบรารีที่เชื่อมโยงและไฟล์ส่วนหัว ( / usr / local / lib และ / usr / local / include ตามลำดับ), man page (/ usr / local / man) และสถาปัตยกรรมอิสระทุกประเภท (/ usr / local / share) รวมถึงเอกสารในรูปแบบอื่น ๆ

/ สาขาเลือก

ไดเร็กทอรี / opt มีให้โดยมาตรฐาน FHS แต่จริงๆ แล้วไม่ได้ใช้ในลีนุกซ์ทุกรุ่น และในระบบ BSD จะไม่มีอยู่เลย อย่างไรก็ตาม มีการเขียนโปรแกรมมากขึ้นเรื่อย ๆ โดยคาดหวังให้การติดตั้งเริ่มต้นอยู่ในนั้น

ในอดีต ไดเร็กทอรี / opt ถูกใช้ใน Linux สำหรับแอปพลิเคชันเชิงพาณิชย์และซอฟต์แวร์ที่ไม่ใช้งานฟรีทุกประเภท ทุกวันนี้ จุดประสงค์ของมันคือเพื่อโฮสต์ระบบซอฟต์แวร์ขนาดใหญ่ในตัว เช่น ไลบรารี Qt, KDE พร้อมส่วนประกอบและแอปพลิเคชันทั้งหมด, OpenOffice.org และอื่นๆ โครงสร้างไดเร็กทอรีควรเป็น / opt / pkg_name นี่คือสิ่งที่ดูเหมือนในระบบของฉัน (Archlinux):

$ ls -1 / opt gnome / kde / OpenOffice.org1.1.2 / qt /

แต่ละไดเรกทอรีย่อยมีโครงสร้างภายในของตัวเอง:

$ ls -1 / opt / * / opt / gnome: bin / lib / man / share / / opt / kde: bin / etc / รวม / lib / share / /opt/OpenOffice.org1.1.2: ความช่วยเหลือ / ใบอนุญาต โปรแกรม html / README README.html [ป้องกันอีเมล]แบ่งปัน / [ป้องกันอีเมล] THIRDPARTYLICENSEREADME.html ผู้ใช้ / / opt / qt: bin / doc / รวม / lib / mkspecs / Phrasebooks / plugins / templates / การแปล /

วัตถุประสงค์ของไดเรกทอรีย่อยภายใน / opt / pkg_name นั้นเดาได้ง่ายโดยการเปรียบเทียบกับ / usr และ / usr / local ตัวอย่างเช่น / opt / kde / bin ใช้สำหรับไฟล์ปฏิบัติการของระบบ KDE และแอปพลิเคชัน / opt / kde / etc สำหรับไฟล์การกำหนดค่า / opt / kde / รวม สำหรับไฟล์ส่วนหัว / opt / kde / lib คือ สำหรับไลบรารีและ / opt / kde / share - สำหรับไฟล์ที่แชร์รวมถึงเอกสารประกอบ ใน KDE ไม่มีเอกสารในรูปแบบ man-format ถ้าเป็นเช่นนั้น (เช่นในกรณีของ Gnome - ฉันไม่ได้ติดตั้งนี่คือสิ่งที่ Gimp และแอปพลิเคชัน Gtk ที่คล้ายกันดึงเข้ามา) คุณสามารถดู / opt / pkg_name / ไดเรกทอรีย่อยชาย

คุณจะเห็นได้ว่าโครงสร้างไดเร็กทอรี / opt นั้นเบี่ยงเบนไปจากโครงสร้างในอดีต (และประเพณี POSIX ที่สมเหตุสมผลภายในของการรวมส่วนประกอบประเภทเดียวกันลงในไดเร็กทอรี - ไฟล์ปฏิบัติการ ไลบรารี ฯลฯ) และด้วยการติดตั้งโปรแกรมจำนวนมากในนั้น สร้างปัญหาบางอย่าง: คุณต้องโอเวอร์โหลดตัวแปร $ PATH ซึ่งให้การเข้าถึงคำสั่งอย่างรวดเร็ว (ซึ่งจะกล่าวถึงในบทที่ 12) หรือสร้างไดเร็กทอรีพิเศษ / opt / bin และใส่ลิงก์สัญลักษณ์ไปยังไบนารีโปรแกรมปฏิบัติการ ดังนั้น ในบางลีนุกซ์ดิสทริบิวชั่น (เช่น ใน CRUX) / opt ไม่ได้ใช้ในหลักการ เหมือนกับในทุกระบบ BSD มันค่อนข้างเป็นไปได้ว่าวิธีนี้จะดีกว่า ...

/ สาขาวาร์

ตามชื่อที่สื่อถึง ไดเร็กทอรี / var มีวัตถุประสงค์เพื่อเก็บไฟล์ที่ไม่แน่นอนซึ่งสร้างขึ้นในช่วงชีวิตปกติของโปรแกรมต่างๆ - แคชซอฟต์แวร์ (เช่น เบราว์เซอร์) ไฟล์บันทึก สพูลการพิมพ์ และระบบเมล กล่องจดหมาย, คำอธิบายของกระบวนการที่ทำงานอยู่ และอื่นๆ โดยเฉพาะอย่างยิ่งมันอยู่ในไดเร็กทอรี / var ที่มีการถ่ายโอนข้อมูลที่เรียกว่า - สแนปชอตของสถานะ RAM ที่สร้างขึ้นในระหว่างการปิดระบบผิดปกติเพื่อระบุสาเหตุของมัน คุณลักษณะที่โดดเด่นของส่วนประกอบทั้งหมดเหล่านี้คือลักษณะที่เปลี่ยนแปลงได้ในระหว่างช่วงการทำงาน และข้อเท็จจริงที่ว่าพวกเขายังคงต้องได้รับการเก็บรักษาไว้เมื่อระบบถูกรีบูต

โครงสร้างภายในของ / var แตกต่างกันไปในแต่ละระบบ ดังนั้นฉันจะไม่อาศัยรายละเอียดของโครงสร้างของมัน ฉันจะทราบเพียงว่าไดเร็กทอรีนี้เป็นสถานที่เชิงตรรกะสำหรับวางส่วนประกอบของระบบการจัดการแพ็คเกจที่เหมือนพอร์ตทุกประเภท เช่น ในการแจกจ่าย Archlinux โดยที่ไดเร็กทอรีย่อย / var / abs (abs - Archlinux Building System) ) สงวนไว้สำหรับมัน

ไดเรกทอรี / mnt

ไดเร็กทอรี / mnt ออกแบบมาเพื่อเมาต์ระบบไฟล์ที่ใช้ชั่วคราว ซึ่งมักจะอยู่บน สื่อที่ถอดออกได้... ในระบบที่จัดตั้งขึ้นทั้งหมด มักจะว่างเปล่า และโครงสร้างของระบบไม่ได้ถูกควบคุมแต่อย่างใด ผู้ใช้มีอิสระในการสร้างไดเรกทอรีย่อยสำหรับสื่อบางประเภท ตัวอย่างเช่น ในระบบของฉัน นี่คือ / mnt / cd, / mnt / dvd, / mnt / usb และ / mnt / hd - สำหรับซีดี ดีวีดี แฟลชไดรฟ์ และฮาร์ดไดรฟ์แบบถอดได้

ใน FreeBSD ไดเร็กทอรีเริ่มต้นสำหรับการติดตั้งซีดีและฟลอปปีดิสก์คือ / cdrom และ / floppy โดยตรงในไดเร็กทอรีราก ซึ่งไม่ค่อยเห็นด้วยกับมาตรฐาน แต่ในทางของตัวเองมันเป็นตรรกะ - จุดเชื่อมต่อของอุปกรณ์ที่มีอยู่ (เช่นซีดีรอม) หรือจนกว่าจะมีอยู่แล้ว (ฟลอปปีไดรฟ์) ในเครื่องใด ๆ จะถูกนำไปที่รูท

/ สาขาบ้าน

ไดเร็กทอรี / home ใช้สำหรับโฮสต์โฮมไดเร็กทอรีของผู้ใช้ เนื้อหาของมันไม่ได้ถูกควบคุม แต่อย่างใด แต่โดยปกติแล้วจะดูเหมือน /home/(username1,...,username#) อย่างไรก็ตาม ในระบบขนาดใหญ่ที่มีผู้ใช้จำนวนมาก โฮมไดเร็กทอรีของพวกเขาสามารถจัดกลุ่มเข้าด้วยกันได้

ไดเร็กทอรี / home สามารถมีโฮมไดเร็กทอรีของผู้ใช้จริงไม่เพียงเท่านั้น แต่ยังรวมถึงผู้ใช้เสมือนบางคนด้วย ดังนั้น หากเครื่องถูกใช้เป็นเว็บหรือเซิร์ฟเวอร์ ftp คุณจะเห็นไดเร็กทอรีย่อย เช่น / home / www หรือ / home / ftp ตามลำดับ

สาขา / tmp

ยังคงพูดถึงเฉพาะไดเร็กทอรีสำหรับจัดเก็บไฟล์ชั่วคราว - / tmp ส่วนประกอบ Like / var นั้นถูกสร้างขึ้นโดยโปรแกรมต่าง ๆ ในช่วงชีวิตปกติ แต่ต่างจาก / var ส่วนประกอบ / tmp จะไม่ถูกบันทึกนอกเซสชันปัจจุบัน นอกจากนี้ คู่มือการดูแลระบบทั้งหมดแนะนำอย่างสม่ำเสมอ (เช่น เมื่อรีสตาร์ทเครื่อง) หรือล้างไดเร็กทอรีนี้เป็นระยะ ดังนั้นในฐานะ / tmp ขอแนะนำให้ติดตั้งระบบไฟล์ใน RAM - tmpfs (ใน Linux) หรือ mfs (ใน FreeBSD) นอกเหนือจากความจริงที่ว่าสิ่งนี้ทำให้มั่นใจได้ว่าเนื้อหาจะถูกล้างเมื่อรีบูต มันยังมีส่วนช่วยในประสิทธิภาพเช่นเมื่อคอมไพล์โปรแกรม ผลิตภัณฑ์ชั่วคราวที่ไม่ได้เขียนลงดิสก์ แต่ถูกวางไว้ในไดเรกทอรีเสมือนเช่น / tmp / ออบจ.

ในหลายระบบ คุณจะเห็นไดเร็กทอรีเช่น / usr / tmp และ / var / tmp สิ่งเหล่านี้มักจะเป็นลิงก์สัญลักษณ์ไปยัง / tmp

กลยุทธ์การแบ่งพาร์ติชั่นระบบไฟล์

ในบทสรุปของการสนทนาเกี่ยวกับลำดับชั้นของไฟล์ ควรเน้นว่าเฉพาะไดเร็กทอรีที่ระบุไว้ในย่อหน้า ระบบไฟล์รูท... ไดเร็กทอรีอื่น ๆ ทั้งหมด - / usr, / opt, / var, / tmp และแน่นอน / home สามารถแสดงจุดเชื่อมต่อของระบบไฟล์อิสระบนสื่อทางกายภาพที่แยกจากกันหรือพาร์ติชั่น

นอกจากนี้ใน เครือข่ายท้องถิ่นไดเร็กทอรีเหล่านี้อาจอยู่ในเครื่องที่แตกต่างกัน ตัวอย่างเช่น คอมพิวเตอร์เครื่องหนึ่งที่ทำหน้าที่เป็นเซิร์ฟเวอร์แอปพลิเคชันอาจมีไดเร็กทอรี / usr และ / opt ในเครือข่าย อีกเครื่องหนึ่งเป็นไฟล์เซิร์ฟเวอร์ที่มีโฮมไดเร็กทอรีของผู้ใช้ทั้งหมด เป็นต้น

สิ่งเดียวที่ต้องทำคือตัดสินใจว่าระบบไฟล์ใดควรแยกจากโครงสร้างไฟล์ทั่วไปและเหตุใดจึงควรทำ คำตอบสำหรับคำถามเหล่านี้ขึ้นอยู่กับระบบปฏิบัติการที่ใช้เป็นอย่างมาก และในกรณีของ Linux ก็ขึ้นอยู่กับการแจกจ่ายด้วย อย่างไรก็ตาม หลักการทั่วไปของการแยกระบบไฟล์สามารถสรุปได้ เหตุใดเราจึงควรจำเกี่ยวกับความขัดแย้งของไดเร็กทอรีที่ไม่เปลี่ยนรูปและเปลี่ยนแปลงได้ในอีกทางหนึ่ง ของข้อมูลที่กู้คืนได้ง่าย กู้คืนยาก และข้อมูลที่ไม่สามารถกู้คืนได้ในทางปฏิบัติ ลองทำสิ่งนี้โดยสัมพันธ์กับเดสก์ท็อปของผู้ใช้ - ในกรณีของเซิร์ฟเวอร์ การคำนวณจะแตกต่างกันอย่างมาก

เห็นได้ชัดว่าระบบไฟล์รูทในไดเร็กทอรี / bin, / boot, / etc, / root, / sbin ที่มีการกู้คืนได้ง่ายจากสื่อการกระจายและข้อมูลที่ไม่เปลี่ยนแปลงในทางปฏิบัติควรอยู่ในพาร์ติชั่นดิสก์แยก บน Linux ควรเพิ่มไดเร็กทอรี / lib ด้วย ในทางกลับกัน เมื่อใช้ GRUB เป็นบูตโหลดเดอร์ (โดยไม่คำนึงถึงระบบปฏิบัติการ) ขอแนะนำให้ย้ายไดเร็กทอรี / boot ไปยังพาร์ติชั่นแยกต่างหาก

ในแหล่งข้อมูลเก่าเกี่ยวกับ Linux คุณสามารถอ่านเกี่ยวกับเหตุผลอื่นในการจัดสรรพาร์ติชันสำหรับไดเร็กทอรีบูต / และที่จุดเริ่มต้นของดิสก์: เนื่องจากความเป็นไปไม่ได้ในการโหลดเคอร์เนลด้วย Lilo จากหมายเลขกระบอกสูบที่สูงกว่า 1023 ใน บูตโหลดเดอร์รุ่นทันสมัยไม่มีข้อ จำกัด ดังกล่าว อย่างไรก็ตาม หากคุณกำลังสร้างพาร์ติชั่นสำหรับ / boot คุณควรทำให้พาร์ติชั่นเป็นพาร์ติชั่นแรกบนดิสก์ และวางพาร์ติชั่นสว็อปไว้ด้านหลัง: การทำเช่นนี้จะเพิ่ม kopecks ห้าตัวให้กับความเร็วเมื่อทำการสลับ

และจากขอบเขตของประวัติศาสตร์: ข้อกำหนดที่รูทและพาร์ติชั่นสำหรับเริ่มระบบเป็นพาร์ติชั่นหลักก็ถูกลบออกไปนานแล้วเช่นกัน และระบบไฟล์เหล่านี้อาจพอดีกับโลจิคัลพาร์ติชันภายใน Extended Partition

เป็นที่ชัดเจนว่ากิ่งที่เปลี่ยนแปลงได้ของระบบไฟล์ — / var และ / tmp — จะต้องถูกย้ายออกนอกพาร์ติชั่นรูท ยิ่งกว่านั้น อย่างที่เคยพูดไปหลายครั้งก่อนหน้านี้ มักจะแนะนำให้วางไว้บนระบบไฟล์ใน RAM (tmpfs หรือ mfs) ในกรณีที่ไดเร็กทอรี / var มีไดเร็กทอรีย่อยสำหรับระบบการจัดการแพ็กเกจที่เหมือนพอร์ต เช่น / var / abs, / var / cache / pacman / src และ / var / cache / pacman / pkg ใน Archlinux ก็ควรสร้างไฟล์ของตนเอง ระบบต่างๆ

ตอนนี้ไดเร็กทอรี / usr ซึ่งมีส่วนประกอบของระบบฐาน (เช่นใน BSD) หรือแอปพลิเคชันผู้ใช้จำนวนมาก (เช่นเดียวกับในลีนุกซ์ส่วนใหญ่) ประกอบด้วยข้อมูลที่กู้คืนได้ง่าย และด้วยเหตุผลที่ดี ไม่ควรเปลี่ยนแปลงในทางปฏิบัติ และแน่นอนว่าควรเน้นในส่วนที่เป็นอิสระ ยิ่งไปกว่านั้น ขอแนะนำให้แยกจากองค์ประกอบของมัน ในอีกด้านหนึ่ง ไดเร็กทอรีย่อย / usr / X11R6 และ / usr / local ในอีกทางหนึ่ง ไดเร็กทอรีย่อยสำหรับระบบการจัดการแพ็คเกจแบบพอร์ต: / usr / ports, / usr / pkgsrc และ / usr / pkg ในระบบ BSD / usr / portages บน Gentoo Linux เป็นต้น นอกจากนี้ ไดเรกทอรีย่อยสำหรับวางแหล่งที่มาที่ดาวน์โหลดจากเครือข่ายเมื่อสร้างพอร์ตควรแยกออกจากส่วนหลัง - / usr / พอร์ต / distfiles, / usr / pkgsrc / disfiles, / usr / portages / distfiles และอื่น ๆ

ในระบบ BSD นอกจากนี้ยังเหมาะสมที่จะแยกไดเรกทอรีย่อยออกจากไดเร็กทอรี / usr ไดเร็กทอรีย่อย / usr / src และ / usr / obj ซึ่งมีแหล่งที่มาของส่วนประกอบพื้นฐาน (รวมถึงเคอร์เนล) และผลิตภัณฑ์ขั้นกลางในการรวบรวมซึ่ง สร้างโดย make buildworld และทำขั้นตอน buildkernel ...

สุดท้าย ไดเร็กทอรีโฮม / ซึ่งประกอบด้วยข้อมูลที่ระเหยและมักจะไม่สามารถกู้คืนได้จะต้องถูกลบออกจากรูทของลำดับชั้นของไฟล์โดยไม่ล้มเหลว และฉันพยายามวางไว้บนสไลซ์แยก (ใน BSD) หรือพาร์ติชั่นหลัก (ใน Linux) เสมอ

รูปแบบการแบ่งพาร์ติชันระบบไฟล์ที่เสนออาจดูซับซ้อนเกินไป อย่างไรก็ตาม รับประกันการแยกข้อมูลที่กู้คืนได้ง่าย กู้คืนยาก และกู้คืนไม่ได้ ซึ่งทำให้ติดตั้งระบบใหม่ในกรณีฉุกเฉินได้ง่ายขึ้น และแม้กระทั่งย้ายจากระบบหนึ่งไปอีกระบบหนึ่ง

ข้อดีเพิ่มเติมคือ สำหรับแต่ละสาขาของโครงสร้างไฟล์ ขึ้นอยู่กับลักษณะของข้อมูลที่อยู่ในนั้น ใน Linux คุณสามารถเลือกระบบไฟล์ที่เหมาะสมที่สุดทางกายภาพ ตัวอย่างเช่น ไม่มีเหตุผลที่จะใช้สิ่งอื่นนอกเหนือจาก Ext2fs สำหรับพาร์ติชั่นภายใต้ / boot โดยทั่วไป ขอแนะนำให้ฟอร์แมตพาร์ติชั่นรูทด้วย Ext3fs ที่ปลอดภัยและยังเข้ากันได้มากที่สุด สำหรับไดเร็กทอรีที่มีไฟล์ขนาดเล็กจำนวนมาก เช่น / var / abs ใน Archlinux, / usr / portages ใน Gentoo ขอแนะนำให้ใช้ ReiserFS: ท้ายที่สุดแล้ว การจัดการไฟล์ขนาดเล็กอย่างมีฝีมือคือโปรไฟล์ และในไดเร็กทอรี / home ซึ่งไฟล์มัลติมีเดียขนาดใหญ่สามารถปรากฏได้ (และโดยปกติแล้วจะมีขนาดใหญ่มาก) XFS อาจมาที่ศาล (แม้ว่าตามการวัดแสดงให้เห็นว่า ReiserFS ดูดีทีเดียวที่นี่) มาตรการดังกล่าวสามารถปรับปรุงทั้งความน่าเชื่อถือของการจัดเก็บข้อมูลและความเร็วของการทำงานของไฟล์

ผู้ใช้ระบบปฏิบัติการ BSD ถูกผูกไว้กับระบบไฟล์ประเภท FFS โดยไม่มีทางเลือกอื่น อย่างไรก็ตาม พวกเขายังมีที่ว่างสำหรับการซ้อมรบ ขั้นแรก โดยการเปลี่ยนขนาดของบล็อกและแฟรกเมนต์ของระบบไฟล์แต่ละระบบ ซึ่งมีส่วนสนับสนุนประสิทธิภาพของการทำงานของดิสก์หรือเพื่อประหยัดพื้นที่ดิสก์ และประการที่สอง แผนผังไฟล์บางสาขา (เช่น / tmp หรือ / usr / obj ซึ่งตรงกันข้ามกับคำแนะนำ สามารถติดตั้งได้ในโหมดอะซิงโครนัสอย่างไม่เกรงกลัวสิ่งใด โดยได้เปอร์เซ็นต์หรือประสิทธิภาพอื่นๆ

เกี่ยวกับมาตรฐานโดยทั่วไป

มีความเห็นในหมู่นักโปรแกรมเมอร์ว่ามาตรฐานในการเขียนโปรแกรมไม่จำเป็นเลย เพราะ:

(1) ในตอนแรกพวกเขาไม่มีความหมายเนื่องจากผู้เขียนไม่ได้เขียนโปรแกรมคอมพิวเตอร์

(2) พวกเขาผูกมัดความคิดริเริ่มของโปรแกรมเมอร์

(3) โปรแกรมเมอร์มักจะเห็นด้วยโดยไม่มีมาตรฐาน

บางทีความคิดเห็นนี้ไม่ควรได้รับความสนใจหากไม่ใช่สำหรับสองสถานการณ์:

(1) มันแสดงออกโดยผู้ปฏิบัติงานนั่นคือผู้ที่ "ออกซอฟต์แวร์" อย่างแม่นยำ

(2) ผู้เขียนบทความนี้ค้นพบเหตุผลข้างต้นในหนึ่งในสิ่งพิมพ์บนอินเทอร์เน็ตที่อุทิศให้กับมาตรฐานสำหรับภาษาการเขียนโปรแกรม C ซึ่งเป็นที่ชัดเจนว่าความคิดเห็นดังกล่าวแพร่หลาย "ในระดับสากล" และไม่เพียง ท่ามกลาง "โปรแกรมเมอร์สุดยอด" ชาวรัสเซียที่หยิ่งผยอง

คำว่า "มาตรฐาน" มักจะเกี่ยวข้องกับวัสดุบางอย่าง (ขนาดมาตรฐาน แรงดันไฟฟ้ามาตรฐาน ฯลฯ) ในขณะที่โปรแกรมคอมพิวเตอร์เป็นวัตถุที่จับต้องไม่ได้ ("สิ่งที่ไม่มีตัวตนใหม่") และมาตรฐานในทรงกลมที่ไม่มีตัวตนอาจไร้ความหมายจริง ๆ เหรอ?

อย่างไรก็ตาม มีตัวอย่างการปฏิเสธ ชุดของกฎการสะกดของภาษารัสเซียนั้นเป็นมาตรฐานหลัก แม้ว่าจะไม่ได้รับอนุมัติจากหน่วยงานมาตรฐานก็ตาม นอกจากนี้ นอกเหนือจากกฎเกณฑ์ (หรือข้อกำหนดในการสะกดคำ) แล้ว ยังมีกฎวากยสัมพันธ์และที่สำคัญที่สุดคือความหมาย อย่างหลังแสดงให้เห็นถึงคำถาม "หน่อมแน้ม": ทำไมแมวถึงเรียกว่าแมว? มีคำตอบที่แน่นอนสำหรับคำถามนี้ เพราะบรรพบุรุษของเราเห็นด้วย บรรพบุรุษของชาวอังกฤษตกลงที่จะเรียกสัตว์เดรัจฉานตัวเดียวกัน บรรพบุรุษของชาวเยอรมัน - ลูกแมว ฯลฯ และโดยทั่วไป ความหมาย หรือความหมาย หรือกฎการตีความคำใดๆ หรือการรวมกันของคำใดๆ ก็ตาม เป็นเรื่องของข้อตกลง

วัตถุประสงค์และ "งานสุดยอด" ของมาตรฐาน POSIX

ตามชื่อที่แนะนำ POSIX (อินเทอร์เฟซระบบปฏิบัติการแบบพกพา) เป็นมาตรฐานสำหรับอินเทอร์เฟซ (อินเทอร์เฟซ) ระหว่างระบบปฏิบัติการและโปรแกรมแอปพลิเคชัน วันที่โปรแกรมเมอร์เขียนโปรแกรมสำหรับเครื่อง "เปล่า" (การนำแพ็คเกจโปรแกรมอินพุต / เอาต์พุต ฟังก์ชันตรีโกณมิติ ฯลฯ ไปใช้) จะหายไปตลอดกาล ข้อความ POSIX เน้นย้ำว่ามาตรฐานไม่ได้กำหนดข้อกำหนดใด ๆ เกี่ยวกับรายละเอียดการใช้งานระบบปฏิบัติการ สามารถดูได้ว่าเป็นชุดของข้อตกลงระหว่างโปรแกรมเมอร์แอปพลิเคชันและนักพัฒนาระบบปฏิบัติการ ดังนั้น (ซึ่งตรงกันข้ามกับความเห็นที่ค่อนข้างแพร่หลาย) POSIX ไม่เพียงเป็นที่สนใจของนักพัฒนาระบบปฏิบัติการเท่านั้น แต่เหนือสิ่งอื่นใดสำหรับโปรแกรมเมอร์ประเภทอื่นๆ อีกมากมาย

ความต้องการมาตรฐานประเภทนี้ได้รับการยอมรับตั้งแต่ช่วงต้นทศวรรษ 1980 เมื่อระบบปฏิบัติการ UNIX เริ่มแพร่หลาย ปรากฎว่าแม้ว่าระบบนี้จะถูกมองว่าเป็นระบบรวม แต่ความแตกต่างระหว่างการใช้งานเฉพาะทำให้ความจริงที่ว่าโปรแกรมแอปพลิเคชันที่เขียนขึ้นสำหรับระบบหนึ่งไม่สามารถดำเนินการในระบบอื่นได้ตลอดเวลา ปัญหานี้เรียกว่าปัญหาการพกพาซอฟต์แวร์ที่ POSIX ตั้งเป้าไว้ มาตรฐานฉบับพิมพ์ครั้งแรกออกในปี 2531 (มีแปลให้ดู) ซึ่งประเด็นต่างๆ ที่เกี่ยวข้องกับการเคลื่อนย้ายโปรแกรมได้แบ่งออกเป็น 2 ส่วนคือ (1) ส่วนต่อประสานโปรแกรมแอปพลิเคชัน (2) ตัวแปลคำสั่งและโปรแกรมอรรถประโยชน์ (ส่วนต่อประสานผู้ใช้ ); ส่วนเหล่านี้เรียกว่า POSIX.1 และ POSIX.2 ตามลำดับ1

ขอชี้แจงว่าในบทความนี้เราจะพูดถึงเฉพาะมาตรฐานสำหรับอินเทอร์เฟซโปรแกรมแอปพลิเคชัน POSIX.1 ซึ่งเป็นรุ่นที่สอง (และล่าสุดจนถึงปัจจุบัน) ซึ่งได้รับการอนุมัติเมื่อวันที่ 12 กรกฎาคม พ.ศ. 2539

ส่วนที่ให้ข้อมูลของมาตรฐานยังเน้นว่า POSIX ไม่ใช่คำอธิบายของอินเทอร์เฟซของระบบปฏิบัติการ "ในอุดมคติ" บางตัว แต่เป็นผลมาจากการวางนัยทั่วไปและการจัดระบบของประสบการณ์ที่ได้รับจากการพัฒนาระบบปฏิบัติการ UNIX นอกจากนี้ POSIX ไม่สามารถทำหน้าที่เป็นไกด์หรือ คู่มือการเรียนบนระบบปฏิบัติการ แม้ว่าส่วนข้อมูลจะมีคำแนะนำสำหรับโปรแกรมเมอร์และส่วนย่อยของโปรแกรม

มาตรฐานระบุโดยตรงว่าเป็นไปไม่ได้ที่จะสร้างระบบปฏิบัติการที่เต็มเปี่ยม โดยเน้นที่ฟังก์ชันอินเทอร์เฟซที่อธิบายไว้ในนั้นเท่านั้น (โดยเฉพาะอย่างยิ่ง POSIX.1 ไม่ได้กล่าวถึงปัญหาต่างๆ เช่น ระบบเครือข่ายและฟังก์ชันอินเทอร์เฟซที่เกี่ยวข้องหรืออินเทอร์เฟซแบบกราฟิก) อย่างไรก็ตาม ค่าใช้จ่ายทางการเงินที่เกี่ยวข้องกับการไม่สามารถเคลื่อนที่ของโปรแกรมและความจำเป็นในการรวมอินเทอร์เฟซได้นั้นยอดเยี่ยมมากจนผู้ขายส่วนใหญ่ต้องการ อย่างน้อยก็มีมาตรฐานมากกว่าไม่มี ด้วยเหตุนี้ นักพัฒนาซอฟต์แวร์จำนวนมากจึงมักจะเน้นที่ POSIX วิธีนี้ช่วยให้หากไม่ขจัดความไม่สามารถเคลื่อนที่ของโปรแกรมได้อย่างสมบูรณ์ อย่างน้อยก็เพื่อลดส่วนที่ไม่สามารถเคลื่อนที่ของโปรแกรมลงได้อย่างมาก

เกี่ยวกับความหมาย

ตามที่กล่าวไว้ก่อนหน้านี้ POSIX สามารถดูเป็นชุดของข้อตกลงระหว่างผู้พัฒนาระบบปฏิบัติการและโปรแกรมเมอร์แอปพลิเคชัน "ข้อตกลง" หมายถึง ประการแรก การตีความคำและสำนวนเดียวกัน (ความหมาย) ต่อไปนี้เป็นตัวอย่างที่แสดงให้เห็นถึงความยากลำบากในการบรรลุ "ข้อตกลง"

วิธีถ่ายทอดความหมายในการแปล

ก่อนอื่นควรจำไว้ว่ามาตรฐาน POSIX เขียนเป็นภาษาอังกฤษ ซึ่งโดยธรรมชาติแล้วจะกระตุ้นให้เกิดความกำกวม (เช่น คำเดียวกันอาจเป็นคำนาม คำคุณศัพท์ และกริยา) และ "กับดักความหมาย" กำลังรออยู่ แทบทุกหน้า ภาพประกอบที่ดีของเรื่องนี้คือตัวอย่างจากนิยาย หนึ่งในผลงานที่โด่งดังที่สุดของ Oscar Wilde ที่ใช้คุณสมบัตินี้อย่างยอดเยี่ยม ของภาษาอังกฤษ, - ความสำคัญของการเป็นคนเอาจริงเอาจัง - เป็นที่รู้จักในภาษารัสเซียว่า "ความสำคัญของการเป็นคนเอาจริงเอาจัง" แต่ ชื่อภาษาอังกฤษมีความหมายที่สอง: จริงจัง (จริงจัง) เป็นนามสกุลของตัวละครตัวใดตัวหนึ่งและชื่อสามารถแปลได้แตกต่างกัน: "การเป็นเอิร์นส์สำคัญแค่ไหน" มีนามสกุลรัสเซีย Serebryany และถ้ามีนามสกุล Serious การแปลจะถูกต้องสมบูรณ์ด้วยการถ่ายโอนความหมายทั้งสอง

สถานการณ์คล้ายกับชื่อมาตรฐาน: Portable Operating System Interface คำคุณศัพท์ Portable (มือถือ) หมายถึงทั้งระบบปฏิบัติการและโปรแกรมแอปพลิเคชัน แต่ไม่สามารถแสดงเป็นภาษารัสเซียสั้น ๆ ได้ มันสามารถแปลว่า "อินเทอร์เฟซของระบบปฏิบัติการมือถือ" หรือ "ส่วนต่อประสานของระบบปฏิบัติการที่ให้ ความคล่องตัวของโปรแกรมการสมัคร”. ตัวเลือกที่สองสะท้อนถึงความตั้งใจของผู้พัฒนามาตรฐานได้ดีกว่า แต่ในขณะเดียวกันความหมายแรกก็หายไป (ระหว่างการแปล ตัวเลือกแรกที่คุ้นเคยจะยังคงอยู่)

ความหมายของคำว่า "มาตรฐาน"

ข้อความหลักของมาตรฐานนำหน้าด้วยคำนำ ซึ่งอธิบายความหมายของคำว่ามาตรฐาน IEEE2 จากคำอธิบายเหล่านี้ มีความแตกต่างอย่างน้อยสามความหมายจากคำศัพท์ภาษารัสเซีย GOST:

(1) โดยสังหรณ์ใจเชื่อว่า GOST มีผลบังคับของกฎหมายซึ่งการละเมิดจะถูกดำเนินคดี; POSIX เป็นชุดของข้อกำหนด การยึดมั่นซึ่งเป็นไปโดยสมัครใจทั้งหมด

(2) GOST ใช้ได้จนกว่าจะถูกยกเลิก (หลายคนคงเคยได้ยินคำว่า "GOST ยังไม่ถูกยกเลิก"); คำนำของ POSIX กล่าวว่าหากไม่มีการแก้ไขมาตรฐานเป็นเวลา 5 ปี หมายความว่าปัญหาที่กล่าวถึงในมาตรฐานนั้นมีแนวโน้มที่จะสูญเสียความเกี่ยวข้องไป และถือว่ายกเลิกโดยอัตโนมัติ

(3) GOST ไม่ระบุชื่อ; ส่วนเบื้องต้นของ POSIX ให้รายชื่อผู้ที่มีส่วนร่วมในการพัฒนามาตรฐานนี้ และยังระบุที่อยู่ที่สามารถส่งคำขอสำหรับการตีความได้ นอกจากนี้ยังระบุด้วยว่าการตอบสนองต่อคำขอแต่ละรายการนั้นขึ้นอยู่กับขั้นตอนการอนุมัติ (กล่าวอีกนัยหนึ่ง ผู้เขียนมาตรฐานตกลงกันเองก่อนที่จะให้คำตอบ)

ดังนั้น การแปลแม้แต่คำที่รู้จักกันดีเช่น Standard โดยคำว่า "มาตรฐาน" จำเป็นต้องมีความคิดเห็น

ความหมายของคำว่า "ควร", "ไม่ระบุ", "ไม่ได้กำหนด", "กำหนดการใช้งาน"

ส่วนที่ 2 ของมาตรฐานเรียกว่า คำศัพท์และข้อกำหนดทั่วไป มันมีคำจำกัดความไม่เพียงแต่ของคำศัพท์พิเศษ (เช่น "กระบวนการ" หรือ "สัญญาณ") แต่ยังมีคำที่ดูเหมือนชัดเจนในตัวเองเช่น "ควร" หรือ "อาจ" เนื่องจาก POSIX.1 เป็นมาตรฐานอินเทอร์เฟซ ความต้องการจึงมีผลกับทั้งระบบปฏิบัติการและโปรแกรมแอปพลิเคชัน ข้อกำหนดที่ชัดเจนจะแสดงด้วยคำว่า "จะ" ตัวอย่างเช่น: "หากสำเร็จ ฟังก์ชันลิงก์ () ต้องคืนค่าศูนย์" ในตัวอย่างนี้ เรากำลังพูดถึงข้อกำหนดของระบบปฏิบัติการ: ฟังก์ชัน link () จะต้องถูกใช้งานเพื่อให้คืนค่าศูนย์เมื่อสำเร็จ

คำว่า "ไม่ได้ระบุ" และ "ไม่ได้กำหนด" เป็นแนวคิดเดียวกันกับที่มาตรฐานอนุญาตให้มีอิสระในการเลือก แต่ความหมายของคำเหล่านี้ต่างกัน คำว่า "ไม่ได้ระบุ" หมายความว่าเรากำลังพูดถึงบางสิ่งที่ถูกต้อง (การกระทำ การสร้างโปรแกรม ฯลฯ) และคำว่า "ไม่ได้กำหนด" - เกี่ยวกับสิ่งที่ไม่ถูกต้อง (ผิดพลาด) ส่วนข้อมูลของมาตรฐานมีคำอธิบายดังต่อไปนี้

คำว่า "unspecified" หมายถึงตัวเลือกต่างๆ (ผลลัพธ์ ผลลัพธ์ของการเรียกใช้ฟังก์ชัน ฯลฯ) เป็นที่ทราบกันดีอยู่แล้ว และมาตรฐานอนุญาตให้ใช้ตัวเลือกใดก็ได้ ในการใช้งานระบบปฏิบัติการโดยเฉพาะ สามารถเลือกระบบใดก็ได้ และระบบดังกล่าวถือว่าเป็นไปตามมาตรฐาน โปรแกรมแอปพลิเคชัน (ตามมาตรฐานอย่างเคร่งครัด) จะต้องเขียนในลักษณะที่ทำงานได้อย่างถูกต้องในทุกรูปแบบ เช่นนี้ ระยะโดยปริยายแสดงข้อกำหนดสำหรับโปรแกรมประยุกต์

มาดูตัวอย่างกัน: “ฟังก์ชัน readdir () ควรส่งคืนตัวชี้ไปยังโครงสร้างที่อ้างอิงถึงองค์ประกอบถัดไปของไดเร็กทอรี มาตรฐานจะส่งคืนรายการแคตตาล็อกที่ชื่อ "point" และ "point-to-point" หรือไม่ " ในตัวอย่างนี้ มีผลลัพธ์ที่เป็นไปได้สี่ประการ และข้อกำหนดสำหรับแอปพลิเคชันคือต้องได้รับการออกแบบสำหรับผลลัพธ์ใดๆ

อีกตัวอย่างหนึ่ง: “ถ้าฟังก์ชัน sigwait () ที่สั่งให้รอสัญญาณที่มีหมายเลขที่ระบุถูกเรียกในเธรดควบคุมหลายอัน ดังนั้นเมื่อสัญญาณมาถึงไม่เกินหนึ่งสัญญาณ sigwait () จะต้องส่งคืน การควบคุมแบบนี้จะเกิดขึ้นไม่ได้กำหนดโดยมาตรฐาน " ในตัวอย่างนี้ อาจมีผลลัพธ์ที่เป็นไปได้มากกว่านี้ แต่ทั้งหมดนั้นทราบกันดีอยู่แล้ว และข้อกำหนดสำหรับแอปพลิเคชันคือต้องทำงานอย่างถูกต้องสำหรับผลลัพธ์ใดๆ

คำว่า "ไม่ได้กำหนด" หมายความว่าไม่ทราบผลลัพธ์จำนวนมาก ผลลัพธ์ใด ๆ ที่เป็นไปได้ แม้แต่ความหายนะ (เช่น ระบบขัดข้อง การสูญหายของข้อมูล ฯลฯ) โดยพื้นฐานแล้ว คำนี้แสดงความต้องการโดยปริยายสำหรับโปรแกรมแอปพลิเคชันที่จะไม่ใช้ข้อมูลหรือโครงสร้างที่เกี่ยวข้อง ตัวอย่างเช่น: "ถ้าอาร์กิวเมนต์ dirp เพื่อ readdir () ไม่ได้อ้างถึงไดเร็กทอรีที่เปิดอยู่ในปัจจุบัน ผลลัพธ์จะไม่ถูกกำหนด"

ตัวอย่างนี้ต้องการให้แอปพลิเคชันแทนที่เฉพาะการอ้างอิงไดเร็กทอรีเปิดสำหรับอาร์กิวเมนต์ฟังก์ชัน readdir () การละเมิดข้อกำหนดนี้อาจนำไปสู่ผลร้ายแรง และความรับผิดชอบสำหรับสิ่งนี้ขึ้นอยู่กับโปรแกรมเมอร์แอปพลิเคชัน

นี่เป็นอีกตัวอย่างหนึ่ง: “หากสำเร็จ ฟังก์ชัน read () ควรส่งคืนจำนวนเต็มแทนจำนวนไบต์ที่อ่านจริง มิฉะนั้น ฟังก์ชันจะต้องกำหนดรหัสข้อผิดพลาดให้กับ errno และคืนค่า -1 และเนื้อหาของบัฟเฟอร์ที่ชี้ไปที่ buf จะไม่ถูกกำหนด "

มาตรฐานนี้ห้ามไม่ให้มีการใช้ข้อมูลจากบัฟเฟอร์ในโปรแกรมแอปพลิเคชันในกรณีที่เกิดข้อผิดพลาดในฟังก์ชันการอ่าน () และผลที่ตามมาของการละเมิดข้อกำหนดนี้จะถูกกำหนดให้กับโปรแกรมเมอร์ของแอปพลิเคชัน

ความหมายของคำว่า "การดำเนินการกำหนด" แตกต่างจากที่เข้าใจได้ง่าย เห็นได้ชัดว่าในระบบปฏิบัติการเฉพาะจะไม่มีผลลัพธ์ "ไม่ระบุ" หรือ "ไม่ได้กำหนด" ผลลัพธ์เฉพาะบางอย่างจะได้รับโดยไม่ล้มเหลว คำว่า "การดำเนินการกำหนด" เป็นการแสดงข้อกำหนดของมาตรฐานสำหรับเอกสารประกอบระบบปฏิบัติการ: ผลลัพธ์ต้องไม่เพียงระบุเท่านั้น (ผู้พัฒนาระบบปฏิบัติการจะต้องทำเช่นนี้) แต่ยังสะท้อนให้เห็นอย่างชัดเจนในเอกสารของระบบ

ความหมายเริ่มต้น

ไม่มีเอกสารกำกับดูแลเพียงฉบับเดียวที่สามารถครอบคลุมกรณีต่างๆ ที่อาจเกิดขึ้นในทางปฏิบัติได้ ดังนั้น จึงหลีกเลี่ยงไม่ได้เกี่ยวกับบางสิ่งบางอย่าง3 ตัวอย่างเช่น คำอธิบายของฟังก์ชันอาจบอกว่าอาร์กิวเมนต์สามารถรับค่าจากช่วงหนึ่งได้ แต่จะไม่มีการพูดถึงผลลัพธ์ที่ได้หากอาร์กิวเมนต์ไม่อยู่ในช่วงนี้ เห็นได้ชัดว่าเพื่อหลีกเลี่ยงความเข้าใจผิด จำเป็นต้องมีความหมายเริ่มต้นที่สม่ำเสมอ ในส่วนข้อมูลของมาตรฐานมีวลีที่น่าสนใจ: "ความหมายที่ยอมรับโดยทั่วไปของค่าเริ่มต้นเป็นสิ่งต้องห้าม" คำแถลงนี้ขัดแย้งกับสโลแกนอายุสิบปีที่รู้จักกันดีว่า เห็นได้ชัดว่ามันฝังแน่นอยู่ในจิตใจของพลเมืองที่หลายคนแม้แต่โปรแกรมเมอร์ก็ไม่เห็นด้วยกับข้อความที่ยกมาของมาตรฐาน ในขณะเดียวกัน หากการใช้โครงสร้างใดๆ ไม่ได้รับอนุญาตอย่างชัดแจ้งและไม่เป็นไปตามคำอธิบาย โปรแกรมเมอร์ที่ฝึกหัดคนใดก็ตามตระหนักดีว่าการใช้โครงสร้างดังกล่าวมีความเสี่ยง และหากไม่ได้ผล จะไม่เกิดขึ้นกับเขาในการเรียกร้อง

กระบวนการและกระแสการควบคุม

คำศัพท์ทั้งสองนี้แสดงถึงแนวคิดของการดำเนินการแบบขนาน เดิมระบบปฏิบัติการ UNIX ถูกมองว่าเป็นผู้ใช้หลายคน และโปรแกรมที่เปิดตัวโดยผู้ใช้ที่แตกต่างกันจะต้องแยกจากกันอย่างน่าเชื่อถือเพื่อไม่ให้บิดเบือนข้อมูล "ของคนอื่น" โดยไม่ได้ตั้งใจ การแยกนี้มาจากข้อเท็จจริงที่ว่าโปรแกรมผู้ใช้ดำเนินการภายในกระบวนการที่พัฒนาในพื้นที่ที่อยู่เสมือนของตัวเอง แม้ว่าโปรแกรมจะมีข้อมูลทั่วโลก แต่เมื่อเปิดตัวในกระบวนการต่างๆ ข้อมูลเหล่านั้นก็จะถูก "กำหนดเส้นทาง" โดยอัตโนมัติไปยังพื้นที่ที่อยู่ที่แตกต่างกัน

อย่างไรก็ตาม กลไกกระบวนการไม่เป็นที่น่าพอใจอย่างสิ้นเชิงเมื่อตั้งโปรแกรมงานแบบเรียลไทม์ แอปพลิเคชันตามเวลาจริง (ทำงานในนามของผู้ใช้รายเดียวกัน) มักจะถูกแสดงโดยธรรมชาติเป็นชิ้นส่วนที่ทำงานพร้อมกันที่เรียกว่า “เธรด” ความแตกต่างที่สำคัญที่สุดจากกระบวนการคือโฟลว์การควบคุมทั้งหมดพัฒนาในพื้นที่ที่อยู่เดียว สิ่งนี้ทำให้เข้าถึงข้อมูลทั่วโลกได้อย่างรวดเร็ว แต่ในขณะเดียวกันก็มีความเสี่ยงที่จะถูกบิดเบือนโดยไม่ได้ตั้งใจ และเพื่อป้องกันไม่ให้สิ่งนี้เกิดขึ้น จำเป็นต้องปฏิบัติตามระเบียบวินัยในการเขียนโปรแกรมบางอย่าง คำแนะนำที่เกี่ยวข้องอยู่ในส่วนข้อมูลของมาตรฐาน

ควรเน้นว่าแนวคิดของการทำมัลติเธรดนั้นถูกนำไปใช้ในระบบปฏิบัติการแบบเรียลไทม์จำนวนมาก และนำไปใช้ในรูปแบบต่างๆ ในแง่ที่ว่าแต่ละเธรดการควบคุมมีชุดแอตทริบิวต์และฟังก์ชันอินเทอร์เฟซต่างกัน บางครั้งใช้คำว่างานแทนเธรด เพื่อหลีกเลี่ยงความสับสน มาตรฐานจึงเน้นว่าเกี่ยวข้องกับเธรด POSIX เท่านั้น และชื่อของฟังก์ชันอินเทอร์เฟซที่เกี่ยวข้องจะถูกนำหน้าด้วย pthread_ (เช่น pthread_create (), pthread_join () เป็นต้น)

เป็นไปตามมาตรฐาน ความหมายของคำว่า "จับคู่"

ตามสัญชาตญาณแล้ว เชื่อกันว่าหากสองรายการถูกสร้างขึ้นตามมาตรฐานเดียวกัน พวกเขาจะรับประกันว่าจะ "ผสมพันธุ์" ซึ่งกันและกัน และจะทำงานร่วมกันเป็นคู่ นี่คือจุดประสงค์ของการแนะนำมาตรฐานอินเทอร์เฟซ (อินเทอร์เฟซ) อย่างแม่นยำ เนื่องจาก POSIX เป็นมาตรฐานอินเทอร์เฟซ เราจึงสามารถพูดคุยเกี่ยวกับการปฏิบัติตามมาตรฐานของทั้งระบบปฏิบัติการและโปรแกรมแอปพลิเคชันได้

มาตรฐาน POSIX.1 มีข้อกำหนดหลายร้อย (ถ้าไม่ใช่หลักพัน) เป็นที่แน่ชัดในตัวเองว่าหากอย่างน้อยหนึ่งในนั้นไม่เป็นไปตามนั้น ระบบ (หรือโปรแกรมแอปพลิเคชัน) ก็ไม่เป็นไปตามมาตรฐาน ในเวลาเดียวกัน ระบบปฏิบัติการและโปรแกรมแอปพลิเคชันคลาส UNIX จำนวนมากได้ถูกเขียนขึ้นจนถึงปัจจุบัน ซึ่งแทบจะไม่สมเหตุสมผลเลยที่จะต้องปฏิบัติตามอย่างครบถ้วนตามความหมายที่ระบุ ความยากลำบากในการพัฒนามาตรฐานสากลประเภทนี้จะทวีความรุนแรงขึ้นจากการมีอยู่ของภาษาประจำชาติที่แตกต่างกัน แม้ว่าเราจะลืมเกี่ยวกับโปรแกรมแอปพลิเคชันที่มีไว้สำหรับการประมวลผลข้อความในภาษาประจำชาติ โปรแกรมแอปพลิเคชันเกือบทั้งหมดจะต้องออกข้อความวินิจฉัยบางประเภทและ/หรือรับรู้ข้อความที่ป้อนโดยผู้ปฏิบัติงาน

• การปฏิบัติตามมาตรฐาน POSIX.1 อย่างเคร่งครัด
• การปฏิบัติตาม POSIX.1 เวอร์ชันสากล
• การปฏิบัติตาม POSIX.1 เวอร์ชันประจำชาติ
• การปฏิบัติตาม POSIX.1 กับส่วนขยาย

ประการที่สอง สิ่งอำนวยความสะดวกอินเทอร์เฟซจำนวนมากเป็นทางเลือก มาตรฐานกำหนดให้ฟังก์ชันอินเทอร์เฟซที่เป็นตัวเลือกต้องได้รับการจัดการตามที่มาตรฐานกำหนดหรือส่งคืนรหัสข้อผิดพลาดพิเศษ ENOSYS เสมอ (หมายความว่าฟังก์ชันนี้ไม่ได้ใช้งาน) สิ่งอำนวยความสะดวกที่เลือกได้จะถูกแบ่งออกเป็นหลายกลุ่ม ซึ่งแต่ละกลุ่มจะสอดคล้องกับค่าคงที่การกำหนดค่าบางอย่าง ซึ่งประกาศ (โดยคำสั่ง #define) ในไฟล์ส่วนหัวที่เกี่ยวข้อง สิ่งนี้ทำให้สามารถค้นหาว่ามีการใช้งานฟังก์ชั่นในระหว่างขั้นตอนการคอมไพล์หรือไม่

วิธีการที่อธิบายไว้ในการบรรลุความคล่องตัวไม่ได้ถูกคิดค้นโดยผู้เขียน POSIX แต่มีการใช้ในทางปฏิบัติมานานแล้ว ในระบบปฏิบัติการหลายระบบ ค่าคงที่การกำหนดค่าใช้เพื่อระบุตัวระบบเองหรือเวอร์ชันของระบบ และในที่นี้มาตรฐานไม่ได้เสนอสิ่งใหม่โดยพื้นฐาน แต่เพียงจัดระบบแนวทางปฏิบัติที่มีอยู่เท่านั้น

วัตถุของมาตรฐานและโครงสร้างของมาตรฐาน

กล่าวโดยย่อ วัตถุมาตรฐาน POSIX.1 คือชื่อและความหมาย โดยเฉพาะอย่างยิ่งเรากำลังพูดถึงสิ่งต่อไปนี้

• ชื่อของฟังก์ชันอินเทอร์เฟซ ฟังก์ชัน 357 เป็นมาตรฐาน โดยมี 107 ฟังก์ชันที่นำมาจากไลบรารี C มาตรฐาน (คณิตศาสตร์ การประมวลผลสตริง อินพุต/เอาต์พุต ฯลฯ) ฟังก์ชันเหล่านี้ถือว่าเป็นส่วนหนึ่งของมาตรฐาน POSIX.1 แต่คือ คำอธิบายแบบเต็มมีอยู่ในมาตรฐานสำหรับภาษาซี
• ชื่อประเภทข้อมูลระบบ ชื่อเหล่านี้ต่อท้ายด้วย _t
• ชื่อของไฟล์ส่วนหัว ตลอดจนองค์ประกอบขั้นต่ำของไฟล์เหล่านี้
• ชื่อตัวแปรส่วนกลางทั้งระบบ (เช่น errno)
• ชื่อสัญลักษณ์ของรหัสข้อผิดพลาดที่สามารถตั้งค่าได้ในระหว่างการเรียกใช้ฟังก์ชัน ชื่อเหล่านี้ขึ้นต้นด้วยตัวอักษร E (EPERM, ENOTEMPTY เป็นต้น)
• ชื่อค่าคงที่ของการกำหนดค่า ชื่อเหล่านี้นำหน้าด้วย _POSIX_
• ชื่อสัญลักษณ์ของหมายเลขสัญญาณ ชื่อเหล่านี้นำหน้าด้วย SIG นอกเหนือจากสัญญาณ "ดั้งเดิม" 20 แบบ (SIGABRT, SIGALRM เป็นต้น) สัญญาณเรียลไทม์ยังเป็นมาตรฐาน ซึ่งตัวเลขดังกล่าวต้องอยู่ในขอบเขตที่ต่อเนื่องกันตั้งแต่ SIGRTMIN ถึง SIGRTMAX ซึ่งประกอบด้วยตัวเลข RTSIG_MAX เป็นอย่างน้อย
• ชื่อสัญลักษณ์ที่สอดคล้องกับค่าของอาร์กิวเมนต์แต่ละรายการของฟังก์ชันบางอย่าง (เช่น อาร์กิวเมนต์ cmd ของฟังก์ชัน fcntl () สามารถใช้ค่า F_DUPFD, F_GETFD, F_GETLK เป็นต้น)
• ชื่อของมาโคร ค่าคงที่ แฟล็กบิต ตัวแปรสภาพแวดล้อม

โดยทั่วไป มาตรฐานประกอบด้วยสองส่วนขนาดใหญ่ที่มีปริมาตรเท่ากันโดยประมาณ ครึ่งแรก - ส่วนเชิงบรรทัดฐาน - มีข้อกำหนดและคำแนะนำของมาตรฐาน (18 ส่วน) ส่วนที่สอง - ส่วนข้อมูล - มีภาคผนวกซึ่งมีรายการอ้างอิงความคิดเห็นและการชี้แจงส่วนบรรทัดฐานองค์ประกอบของส่วนหัว ไฟล์ ตัวอย่างของโปรไฟล์ ("การฉายภาพ") ของมาตรฐาน ( สำหรับเดนมาร์ก) ลักษณะและวิธีการในการวัดประสิทธิภาพของฟังก์ชันที่สำคัญที่สุด ตลอดจนคำอธิบายของฟังก์ชันอินเทอร์เฟซเพิ่มเติมสำหรับการทำงานกับไฟล์แบบเรียลไทม์ คาดว่าในรุ่นต่อๆ ไปของมาตรฐาน ฟังก์ชันเหล่านี้จะรวมอยู่ในส่วนกฎเกณฑ์

แถบด้านข้าง "บทสรุปของมาตรามาตรฐาน" ให้แนวคิดเกี่ยวกับประเภทของบริการระบบปฏิบัติการที่ครอบคลุมโดยมาตรฐาน

บทสรุป

เนื้อหาหลักของมาตรฐาน POSIX คือความหมายของฟังก์ชันอินเทอร์เฟซ การกำหนดมาตรฐานของความหมายไม่ใช่เรื่องง่ายในตัวเอง (ทุกคนรู้ดีว่าการบรรลุข้อตกลงสำหรับสองคนนั้นยากเพียงใด) และความยากลำบากนั้นรุนแรงขึ้นจากข้อเท็จจริงที่ว่าผู้คนจำนวนมากมีส่วนร่วมในการเขียนโปรแกรมในปัจจุบัน ตัวอย่างเช่น กระบวนทัศน์การทำงานพร้อมกันจะแสดงออกมาในรูปของ "กระบวนการ" "งาน" และ "ขั้นตอนการควบคุม" แต่จากมุมมองของการเขียนโปรแกรมเชิงปฏิบัติ "งาน" ในระบบปฏิบัติการ IBM OS / 360 และของจริง เวลาระบบปฏิบัติการ VxWorks ไม่เหมือนกัน และยัง อีกตัวอย่างหนึ่งคือสัญญาณ สัญญาณเป็นเลขฐานสองจำนวนเต็ม ("กับตัวนับ") และการยกเว้นร่วมกัน (ซึ่งโดยวิธีการที่โปรแกรมเมอร์เรียกตัวเองว่า "mutexes" ซึ่งพยายามหลีกเลี่ยงความเข้าใจผิดโดยธรรมชาติ) และเซมาฟอร์จำนวนเต็ม เช่น ในระบบปฏิบัติการ VxWorks นั้นไม่เหมือนกับสัญญาณ POSIX เลย

ผู้เขียนมาตรฐาน POSIX ตระหนักดีถึงความยากลำบากในการทำให้ผู้คนละทิ้งนิสัยของตน (ซึ่งพวกเขาเรียกว่า "การปฏิบัติที่จัดตั้งขึ้น") ประกาศว่าพวกเขาได้รวบรวมระบบอินเทอร์เฟซที่เชื่อมโยงกันและน้อยที่สุดซึ่งครอบคลุมบริการส่วนใหญ่ตามประเพณี โดยระบบปฏิบัติการ อธิบายรายละเอียดเกี่ยวกับความหมายที่แท้จริงของฟังก์ชันเหล่านี้ และเชิญทุกคนให้ใช้ฟังก์ชันเหล่านี้ในการพัฒนา4

เมื่ออ่านมาตรฐานแล้ว บางครั้งเรารู้สึกว่าถ้อยคำบางคำมีจุดประสงค์เดียว นั่นคือ ไม่ใช่เพื่อลบโปรแกรมแอปพลิเคชันหรือระบบปฏิบัติการบางรายการออกจากหมวดหมู่ที่ตรงตามมาตรฐาน เป้าหมายดังกล่าวถูกกำหนดและกำหนดไว้อย่างชัดเจนในบทนำ: มาตรฐานควรคำนึงถึงแนวทางปฏิบัติที่มีอยู่ให้มากที่สุด อย่างไรก็ตาม เป้าหมายหลักยังคงเป็นการประกันความคล่องตัวของโปรแกรมการสมัคร

เกี่ยวกับผู้เขียน

Sergey Romanyuk - นักวิจัยอาวุโสที่สถาบันวิจัยเพื่อการวิจัยระบบ หัวหน้ากลุ่มนักแปลมาตรฐาน POSIX สามารถติดต่อได้ทางอีเมล์ที่ [ป้องกันอีเมล]

1 ควรเสริมว่าการทำงานเกี่ยวกับมาตรฐานนั้นดำเนินมาหลายปีแล้ว มีการระบุปัญหาใหม่ และรวมไว้ในส่วนใดส่วนหนึ่งที่มีอยู่ หรือทำให้เป็นทางการเป็นส่วนแยกต่างหาก ซึ่งสามารถยกเลิกได้ในภายหลัง เหตุการณ์นี้เกิดขึ้นกับสิ่งอำนวยความสะดวกส่วนหน้าแบบเรียลไทม์ ซึ่งประกาศครั้งแรกเป็น POSIX.4 และรวมอยู่ใน POSIX.1 ในภายหลัง

2 IEEE เป็นองค์กรที่พัฒนามาตรฐาน POSIX

3 ในที่นี้ "ค่าเริ่มต้น" หมายถึงเงียบ ไม่ใช่ค่าเริ่มต้น เราไม่ได้พูดถึงค่าโดยนัยใด ๆ ที่มีการประกาศจริง แต่เกี่ยวกับการไม่มีการอ้างอิงเลย

4 มาตรฐานการแปลเป็นภาษารัสเซียจะเผยแพร่ในต้นปี 2000

วรรณกรรม

มาตรฐานสากล ISO / IEC 9945-1 (ANSI / IEEE Std 1003.1) ฉบับที่สอง 1996-07-12. เทคโนโลยีสารสนเทศ - Portable Operating System Interface (POSIX) - ส่วนที่ 1: System Application Program Interface (API)

M.I.Belyakov, Yu.I. Rabover, A.L. Fridman. ระบบปฏิบัติการมือถือ ไดเรกทอรี มอสโก "วิทยุและการสื่อสาร", 1991

ISO / IEC 9899: 1990 ภาษาโปรแกรม - C.

ส่วนที่ 1	- บทนำ
มาตรา 2	- คำศัพท์และคำจำกัดความ
มาตรา 3	- ฟังก์ชั่นสำหรับจัดการกระบวนการ (สร้าง แทนที่รูปภาพ เสร็จสิ้น) และสัญญาณ (จัดการมาสก์ ตอบสนองต่อสัญญาณ)
มาตรา 4	- การระบุ (กระบวนการ, ผู้ใช้, ระบบ, เทอร์มินัล), การหยั่งเสียงเวลาที่ใช้ในการดำเนินการของกระบวนการ, การสำรวจตัวแปรสภาพแวดล้อม
มาตรา 5	- การจัดการไฟล์และไดเรกทอรี
มาตรา 6	- ฟังก์ชันอินพุตและเอาต์พุต
มาตรา 7	- ฟังก์ชั่นการควบคุมเทอร์มินัล
มาตรา 8	- ฟังก์ชั่นที่ยืมมาจากมาตรฐานภาษา C
มาตรา 9	- การเข้าถึงฐานข้อมูลของผู้ใช้และกลุ่มผู้ใช้
มาตรา 10	- รูปแบบข้อมูลสำหรับเก็บถาวรและแลกเปลี่ยน (tar และ cpio)
มาตรา 11	- สิ่งอำนวยความสะดวกการซิงโครไนซ์: สัญญาณ mutexes และตัวแปรเงื่อนไข
มาตรา 12	- ฟังก์ชันการจัดการหน่วยความจำ: การตรึงและเลิกตรึงพื้นที่ที่อยู่ของกระบวนการ การจับคู่ไฟล์กับหน่วยความจำ การป้องกันหน่วยความจำ หน่วยความจำที่ใช้ร่วมกัน
มาตรา 13	- ฟังก์ชั่นที่เกี่ยวข้องกับกระบวนการจัดตารางเวลาและโฟลว์การควบคุม
มาตรา 14	- การจัดการนาฬิกาและตัวจับเวลา
มาตรา 15	- การจัดการคิวข้อความ
มาตรา 16	- ฟังก์ชันพื้นฐานที่เกี่ยวข้องกับการควบคุมโฟลว์
มาตรา 17	- ข้อมูลเฉพาะเธรด
มาตรา 18	- หมายถึงการทำลายกระแสควบคุม

หัวเรื่อง : ระบบปฏิบัติการ.
คำถาม: หมายเลข 8

—————————————————————

หลักการสร้างระบบปฏิบัติการ:

1.) หลักการโมดูลาร์- โดยทั่วไปแล้วโมดูลจะหมายถึงองค์ประกอบที่สมบูรณ์ของระบบซึ่งสร้างขึ้นตามอินเทอร์เฟซระหว่างโมดูลที่ยอมรับ ตามคำจำกัดความ โมดูลจะถือว่าสามารถแทนที่ด้วยโมดูลอื่นได้อย่างง่ายดาย โดยมีเงื่อนไขว่าอินเทอร์เฟซที่ระบุพร้อมใช้งาน ส่วนใหญ่ การแบ่งระบบออกเป็นโมดูลจะถูกกำหนดโดยวิธีการออกแบบระบบปฏิบัติการที่ใช้ (จากล่างขึ้นบนหรือกลับกัน)

โมดูลที่ได้รับสิทธิ์ กลับเข้ามาใหม่ และกลับเข้ามาใหม่มีความสำคัญเป็นพิเศษเมื่อสร้างระบบปฏิบัติการ (การให้สิทธิ์ใหม่เป็นการให้สิทธิ์ใหม่ตามตัวอักษร คำพิเศษที่แสดงถึงความสมบูรณ์ของโปรแกรม คุณสมบัติของโปรแกรมที่จะดำเนินการได้อย่างถูกต้องเมื่อ เรียกซ้ำ (ส่งคืน) จากการขัดจังหวะเกิดขึ้น)

ผลกระทบที่ยิ่งใหญ่ที่สุดจากการใช้หลักการนี้สามารถทำได้ในกรณีที่มีการขยายหลักการนี้ไปยังระบบปฏิบัติการ โปรแกรมแอปพลิเคชัน และฮาร์ดแวร์พร้อมกัน

2.) หลักการเลือกการทำงาน- ส่วนหนึ่งของโมดูลที่สำคัญได้รับการจัดสรรในระบบปฏิบัติการซึ่งจะต้องอยู่ใน RAM อย่างต่อเนื่องเพื่อให้องค์กรมีประสิทธิภาพมากขึ้นของกระบวนการคำนวณ ส่วนนี้เรียกว่าเคอร์เนลในระบบปฏิบัติการเนื่องจากเป็นพื้นฐานของระบบ เมื่อสร้างองค์ประกอบของนิวเคลียสจะต้องคำนึงถึงข้อกำหนดสองข้อที่ขัดแย้งกัน ในอีกด้านหนึ่ง โมดูลระบบที่ใช้บ่อยที่สุดควรรวมอยู่ในเคอร์เนล อีกด้านหนึ่ง จำนวนโมดูลควรเป็นจำนวนที่หน่วยความจำที่เคอร์เนลครอบครองไม่มากเกินไป นอกจากโมดูลซอฟต์แวร์ที่เป็นส่วนหนึ่งของเคอร์เนลและอยู่ใน RAM ถาวรแล้ว ยังมีโมดูลซอฟต์แวร์ระบบอื่นๆ อีกมากมายที่เรียกว่า ทางผ่าน. ทางผ่าน โมดูลซอฟต์แวร์โหลดลงใน RAM เฉพาะเมื่อจำเป็นและในกรณีที่ไม่มี ที่ว่างสามารถแทนที่ด้วยโมดูลการขนส่งอื่น ๆ

3.) หลักการของความสามารถในการสร้างระบบปฏิบัติการ:สาระสำคัญของหลักการประกอบด้วยการจัดระเบียบ (การเลือก) วิธีการดังกล่าวสำหรับการนำเสนอเบื้องต้นของโปรแกรมควบคุมระบบส่วนกลางของระบบปฏิบัติการ (เคอร์เนลและส่วนประกอบหลักอย่างถาวรใน RAM) ซึ่งทำให้สามารถปรับแต่งส่วนควบคุมระบบนี้ได้ ขึ้นอยู่กับการกำหนดค่าเฉพาะของคอมเพล็กซ์การคำนวณเฉพาะและช่วงของงานที่จะแก้ไข ขั้นตอนนี้ดำเนินการไม่บ่อยนักก่อนที่ระบบปฏิบัติการจะมีระยะเวลาการทำงานนานพอสมควร ขั้นตอนการสร้างดำเนินการโดยใช้โปรแกรมสร้างพิเศษและภาษาอินพุตที่เหมาะสมสำหรับโปรแกรมนี้ ซึ่งช่วยให้สามารถอธิบายความสามารถของซอฟต์แวร์ของระบบและการกำหนดค่าของเครื่อง ผลลัพธ์ของรุ่นคือ เวอร์ชันเต็มระบบปฏิบัติการ เวอร์ชันของระบบปฏิบัติการที่สร้างขึ้นคือชุดของชุดโมดูลและข้อมูลของระบบ

4.) หลักการทำงานซ้ำซ้อน:หลักการนี้คำนึงถึงความเป็นไปได้ในการทำงานเดียวกันด้วยวิธีการที่แตกต่างกัน ระบบปฏิบัติการอาจประกอบด้วยการมอนิเตอร์หลายประเภท (โมดูลหัวหน้างานที่ควบคุมทรัพยากรประเภทใดประเภทหนึ่ง) วิธีการต่างๆ ในการจัดระเบียบการสื่อสารระหว่างกระบวนการคำนวณ การมีอยู่ของจอภาพหลายประเภท ระบบการจัดการไฟล์หลายแบบทำให้ผู้ใช้สามารถปรับ OS ได้อย่างรวดเร็วและเพียงพอที่สุดกับการกำหนดค่าเฉพาะของระบบคอมพิวเตอร์ เพื่อให้แน่ใจว่าการโหลดฮาร์ดแวร์อย่างมีประสิทธิภาพสูงสุดเมื่อแก้ไขปัญหาเฉพาะกลุ่ม เพื่อให้ได้ผลลัพธ์สูงสุด ประสิทธิภาพในการแก้ปัญหาระดับที่กำหนด

5.) หลักการการจำลองเสมือน:การสร้างทรัพยากรเสมือน การกระจายและการใช้งานในปัจจุบันมีการใช้งานในเกือบทุกระบบปฏิบัติการ หลักการนี้ช่วยให้คุณแสดงโครงสร้างของระบบในรูปแบบของชุดตัวกำหนดตารางเวลากระบวนการและตัวจัดสรรทรัพยากร (จอภาพ) ที่เฉพาะเจาะจง และใช้รูปแบบการจัดสรรทรัพยากรแบบรวมศูนย์เดียว

การแสดงออกที่เป็นธรรมชาติและสมบูรณ์ที่สุดของแนวคิดของเวอร์ชวลคือแนวคิด เครื่องเสมือน ... เครื่องเสมือนที่มอบให้แก่ผู้ใช้สร้างสถาปัตยกรรมของเครื่องจริง แต่องค์ประกอบทางสถาปัตยกรรมในการนำเสนอนี้ปรากฏขึ้นพร้อมกับคุณลักษณะใหม่หรือที่ปรับปรุง ซึ่งตามกฎแล้ว จะทำให้การทำงานกับระบบง่ายขึ้น ลักษณะเฉพาะสามารถกำหนดเองได้ แต่ผู้ใช้ส่วนใหญ่มักต้องการมีเครื่อง "ในอุดมคติ" ของตนเองในแง่ของลักษณะทางสถาปัตยกรรมในองค์ประกอบต่อไปนี้:

- หน่วยความจำเสมือนของปริมาณไม่ จำกัด ในทางปฏิบัติเหมือนกันในแง่ของตรรกะของการทำงาน

- จำนวนตัวประมวลผลเสมือนที่สามารถทำงานแบบขนานและโต้ตอบระหว่างการทำงานได้ตามอำเภอใจ

- จำนวนอุปกรณ์เสมือนภายนอกตามอำเภอใจที่สามารถทำงานกับหน่วยความจำของเครื่องเสมือนในแบบคู่ขนานหรือตามลำดับ แบบอะซิงโครนัสหรือแบบซิงโครนัสในส่วนที่เกี่ยวกับการทำงานของโปรเซสเซอร์เสมือนหนึ่งหรือตัวอื่นที่เริ่มต้นการทำงานของอุปกรณ์เหล่านี้

แง่มุมหนึ่งของเวอร์ชวลไลเซชันคือการจัดระเบียบความเป็นไปได้ของการทำงานในแอปพลิเคชันระบบปฏิบัติการที่กำหนดซึ่งพัฒนาขึ้นสำหรับระบบปฏิบัติการอื่น เรากำลังพูดถึงการจัดสภาพแวดล้อมการทำงานหลายอย่าง

6.) หลักการความเป็นอิสระของโปรแกรมจากอุปกรณ์ภายนอก:หลักการนี้ถูกนำมาใช้ในระบบปฏิบัติการทั่วไปส่วนใหญ่ เป็นครั้งแรกที่หลักการนี้ถูกนำมาใช้อย่างสม่ำเสมอที่สุดใน UNIX OS มันยังถูกนำมาใช้ในระบบปฏิบัติการพีซีที่ทันสมัยที่สุด หลักการนี้อยู่ในความจริงที่ว่าการเชื่อมต่อของโปรแกรมกับอุปกรณ์เฉพาะนั้นไม่ได้ดำเนินการในระดับการออกอากาศโปรแกรม แต่ในช่วงระยะเวลาการวางแผนของการดำเนินการ เป็นผลให้ไม่จำเป็นต้องคอมไพล์ใหม่เมื่อโปรแกรมกำลังทำงานกับอุปกรณ์ใหม่ที่มีข้อมูลอยู่

7.) หลักการความเข้ากันได้:ด้านหนึ่งของความเข้ากันได้คือความสามารถของระบบปฏิบัติการในการเรียกใช้โปรแกรมที่เขียนขึ้นสำหรับระบบปฏิบัติการอื่นหรือสำหรับระบบปฏิบัติการเวอร์ชันก่อนหน้า รวมทั้งสำหรับแพลตฟอร์มฮาร์ดแวร์อื่น มีความจำเป็นต้องแยกคำถาม ความเข้ากันได้ของไบนารีและ ความเข้ากันได้ของแหล่งที่มาแอปพลิเคชัน

ความเข้ากันได้แบบไบนารีจะเกิดขึ้นได้เมื่อคุณสามารถใช้โปรแกรมปฏิบัติการและรันบนระบบปฏิบัติการอื่นได้ สิ่งนี้ต้องการความเข้ากันได้ที่ระดับของคำสั่งโปรเซสเซอร์ และความเข้ากันได้ที่ระดับของการเรียกระบบ และแม้กระทั่งในระดับของการเรียกไลบรารี หากมีการลิงก์แบบไดนามิก

ความเข้ากันได้ของแหล่งที่มาต้องการนักแปลที่เหมาะสมในซอฟต์แวร์ระบบ เช่นเดียวกับความเข้ากันได้ของไลบรารีและการโทรของระบบ ในกรณีนี้ จำเป็นต้องคอมไพล์ข้อความต้นฉบับที่มีอยู่ใหม่ให้เป็นโมดูลปฏิบัติการใหม่

เป็นการยากที่จะบรรลุความเข้ากันได้แบบไบนารีระหว่างโปรเซสเซอร์ตามสถาปัตยกรรมที่แตกต่างกัน เพื่อให้คอมพิวเตอร์เครื่องหนึ่งสามารถรันโปรแกรมของอีกเครื่องหนึ่งได้ (เช่น โปรแกรมสำหรับพีซีเช่น IBM PC เป็นที่พึงปรารถนาให้ทำงานบนพีซี เช่น Apple Macintosh) คอมพิวเตอร์เครื่องนี้ต้องทำงานกับคำสั่งเครื่องที่ยังไม่ได้เริ่มต้น เข้าใจ. ในกรณีนี้ โปรเซสเซอร์ 680x0 (หรือ PowerPC) ต้องดำเนินการ รหัสไบนารีออกแบบมาสำหรับโปรเซสเซอร์ i80x86 โปรเซสเซอร์ 80x86 มีตัวถอดรหัสคำสั่ง รีจิสเตอร์ และสถาปัตยกรรมภายในของตัวเอง โปรเซสเซอร์ 680x0 ไม่เข้าใจไบนารี 80x86 ดังนั้นจึงต้องเลือกแต่ละคำสั่ง ถอดรหัสเพื่อพิจารณาว่า

สิ่งที่ตั้งใจจะทำ จากนั้นรันรูทีนย่อยเทียบเท่าที่เขียนขึ้นสำหรับ 680 × 0

วิธีหนึ่งในการรับรองความเข้ากันได้ของซอฟต์แวร์และอินเทอร์เฟซผู้ใช้คือการปฏิบัติตามมาตรฐาน POSIX ซึ่งช่วยให้คุณสร้างโปรแกรมสไตล์ UNIX ที่เคลื่อนย้ายได้ง่ายในภายหลังจากระบบหนึ่งไปอีกระบบหนึ่ง

8.) หลักการเปิดกว้างและขยายได้:ระบบปฏิบัติการแบบเปิดพร้อมสำหรับการวิเคราะห์โดยทั้งผู้ใช้และผู้เชี่ยวชาญระบบที่ดูแลระบบคอมพิวเตอร์ OS ที่ขยายได้ (แก้ไขได้ พัฒนาแล้ว) ไม่เพียงแต่อนุญาตให้ใช้ความสามารถในการสร้าง แต่ยังแนะนำโมดูลใหม่เข้าไปในองค์ประกอบ ปรับปรุงโมดูลที่มีอยู่ ฯลฯ กล่าวอีกนัยหนึ่ง ควรเพิ่มและเปลี่ยนแปลงได้อย่างง่ายดายตามความจำเป็นโดยไม่กระทบต่อความสมบูรณ์ของระบบ แนวทางไคลเอนต์-เซิร์ฟเวอร์ในการจัดโครงสร้างระบบปฏิบัติการโดยใช้เทคโนโลยีไมโครนิวเคลียร์ให้โอกาสที่ยอดเยี่ยมสำหรับการขยายตัว ตามแนวทางนี้ ระบบปฏิบัติการถูกสร้างขึ้นเป็นชุดของโปรแกรมควบคุมที่มีสิทธิพิเศษและชุดของบริการ (เซิร์ฟเวอร์) ที่ไม่มีสิทธิพิเศษ ส่วนหลักของระบบปฏิบัติการยังคงไม่เปลี่ยนแปลง และในขณะเดียวกันก็สามารถเพิ่มเซิร์ฟเวอร์ใหม่หรือปรับปรุงเซิร์ฟเวอร์เก่าได้ หลักการนี้บางครั้งตีความว่า ความสามารถในการขยายระบบ.

9.) หลักการเคลื่อนย้าย:ระบบปฏิบัติการควรจะค่อนข้างง่ายต่อการพกพา

เพื่อเชื่อมต่อจากโปรเซสเซอร์ประเภทหนึ่งไปยังโปรเซสเซอร์ประเภทอื่นและจากแพลตฟอร์มฮาร์ดแวร์ประเภทหนึ่งซึ่งรวมถึงประเภทของโปรเซสเซอร์และวิธีการจัดระเบียบฮาร์ดแวร์คอมพิวเตอร์ทั้งหมด (สถาปัตยกรรมระบบคอมพิวเตอร์) ไปยังแพลตฟอร์มฮาร์ดแวร์ประเภทอื่น . โปรดทราบว่าหลักการของการพกพานั้นใกล้เคียงกับหลักการของความเข้ากันได้มาก แม้ว่าจะไม่ใช่สิ่งเดียวกันก็ตาม การเขียน OS แบบพกพานั้นคล้ายกับการเขียนโค้ดแบบพกพาใดๆ แต่คุณต้องปฏิบัติตามบ้าง กฎ:

- ระบบปฏิบัติการส่วนใหญ่จะต้องดำเนินการในภาษาที่มีอยู่ในระบบทั้งหมดที่มีการวางแผนให้พอร์ตในภายหลัง ก่อนอื่นหมายความว่า OS จะต้องเขียนในภาษา ระดับสูง, ควรกำหนดมาตรฐาน, ตัวอย่างเช่นใน C. โปรแกรมที่เขียนในแอสเซมบลีโดยทั่วไปไม่สามารถพกพาได้

- สิ่งสำคัญคือต้องย่อให้เล็กสุดหรือยกเว้นส่วนต่างๆ ของโค้ดที่โต้ตอบกับฮาร์ดแวร์โดยตรง หากเป็นไปได้ การพึ่งพาฮาร์ดแวร์สามารถมีได้หลายรูปแบบ รูปแบบการพึ่งพาที่ชัดเจนบางรูปแบบรวมถึงการจัดการการลงทะเบียนและฮาร์ดแวร์อื่นๆ โดยตรง สุดท้าย หากไม่สามารถแยกโค้ดที่ขึ้นกับฮาร์ดแวร์ได้อย่างสมบูรณ์ ก็ควรแยกโค้ดนั้นออกเป็นโมดูลที่มีโลคัลไลซ์อย่างดีหลายโมดูล ไม่จำเป็นต้องแจกจ่ายรหัสที่ขึ้นกับฮาร์ดแวร์ทั่วทั้งระบบ ตัวอย่างเช่น คุณสามารถซ่อนโครงสร้างที่ขึ้นอยู่กับฮาร์ดแวร์ในชนิดข้อมูลนามธรรมที่ตั้งโปรแกรมได้

การแนะนำมาตรฐาน POSIX มีวัตถุประสงค์เพื่อสร้างความมั่นใจในการพกพาของซอฟต์แวร์ที่สร้างขึ้น

10.) หลักการรักษาความปลอดภัยคอมพิวเตอร์:การรับรองความปลอดภัยทางคอมพิวเตอร์เป็นคุณสมบัติที่พึงประสงค์สำหรับระบบที่มีผู้ใช้หลายคน กฎความปลอดภัยกำหนดคุณสมบัติ เช่น การปกป้องทรัพยากรของผู้ใช้รายหนึ่งจากผู้อื่น และการตั้งค่าโควตาทรัพยากรเพื่อป้องกันไม่ให้ผู้ใช้รายหนึ่งเข้ายึดทรัพยากรระบบทั้งหมด เช่น หน่วยความจำ

การปกป้องข้อมูลจากการเข้าถึงโดยไม่ได้รับอนุญาตถือเป็นหน้าที่บังคับของระบบปฏิบัติการเครือข่าย

—————————————————————

อะไรPOSIX: อินเทอร์เฟซระบบที่ไม่ขึ้นกับแพลตฟอร์มสำหรับสภาพแวดล้อมคอมพิวเตอร์ POSIX (อินเทอร์เฟซระบบปฏิบัติการแบบพกพาสำหรับสภาพแวดล้อมคอมพิวเตอร์) เป็นมาตรฐาน IEEE (สถาบันวิศวกรไฟฟ้าและอิเล็กทรอนิกส์) ที่อธิบายอินเทอร์เฟซระบบสำหรับระบบปฏิบัติการแบบเปิด รวมถึงเชลล์ ยูทิลิตี้ และชุดเครื่องมือ นอกจากนี้ งานด้านความปลอดภัยที่ได้มาตรฐาน POSIX งานแบบเรียลไทม์ กระบวนการบริหาร ฟังก์ชันเครือข่าย และการประมวลผลธุรกรรม มาตรฐานนี้ใช้ระบบ UNIX แต่สามารถนำไปใช้กับระบบปฏิบัติการอื่นได้เช่นกัน POSIX เกิดขึ้นจากความพยายามทั่วโลก องค์กรที่มีชื่อเสียง IEEE ส่งเสริมการพกพาแอปพลิเคชันในสภาพแวดล้อม UNIX โดยการพัฒนามาตรฐานนามธรรมที่ไม่ขึ้นกับแพลตฟอร์ม ตัวอย่างเช่น OS QNX แบบเรียลไทม์ที่รู้จักกันดีนั้นสอดคล้องกับข้อกำหนดของมาตรฐานนี้

มาตรฐานนี้ให้รายละเอียดเกี่ยวกับระบบหน่วยความจำเสมือน VMS (Virtual Memory System), มัลติทาสกิ้ง MPE (Multi-Process Executing) และระบบปฏิบัติการที่สร้าง Convergent Technology ... (CTOS) ดังนั้น POSIX จึงเป็นชุดของมาตรฐานที่เรียกว่า POSIX.I –POSIX.12 ควรสังเกตด้วยว่า POSIX.1 ถือว่า C เป็นภาษาหลัก

ฟังก์ชันระบบ API คำอธิบายภาษา

ดังนั้น โปรแกรมที่เขียนตามมาตรฐานเหล่านี้จะทำงานเหมือนกันบนระบบที่สอดคล้องกับ POSIX ทั้งหมด อย่างไรก็ตาม ในบางกรณีมาตรฐานเป็นเพียงคำแนะนำในลักษณะเท่านั้น มาตรฐานบางอย่างได้รับการอธิบายไว้อย่างเคร่งครัด ในขณะที่ส่วนอื่น ๆ จะเปิดเผยข้อกำหนดพื้นฐานเพียงผิวเผินเท่านั้น

การใช้งานระบบปฏิบัติการของ POSIX API นั้นแตกต่างกัน หากระบบ UNIX ส่วนใหญ่เริ่มปฏิบัติตามข้อกำหนด IEEE Standard 1003.1-1990 แล้ว WinAPI จะไม่เป็นไปตามข้อกำหนด POSIX อย่างไรก็ตาม เพื่อสนับสนุนมาตรฐานนี้ในระบบปฏิบัติการ MS Windows NT เราได้แนะนำโมดูลสนับสนุน POSIX API พิเศษที่ทำงานในระดับสิทธิ์พิเศษของกระบวนการของผู้ใช้

โมดูลนี้ให้การแปลงและโอนการเรียกจากโปรแกรมผู้ใช้ไปยังเคอร์เนลของระบบและย้อนกลับ โดยทำงานกับเคอร์เนลผ่าน Win API แอปพลิเคชันอื่นๆ ที่สร้างโดยใช้ WinAPI สามารถส่งข้อมูลไปยังแอปพลิเคชัน POSIX ผ่านกลไกการสตรีม I / O มาตรฐาน (stdin, stdout)

ไม่มีกระทู้ที่เกี่ยวข้อง...