POSIX ve OS RT: bir sistemleştirme girişimi. POSIX standardının temel kavramları ve fikirleri

Konu: İşletim sistemleri.
Soru: 8 numara

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

İşletim sistemi oluşturma ilkeleri:

1.) Modülerlik ilkesi- bir modül genellikle, kabul edilen modüller arası arayüzlere uygun olarak yapılan, sistemin işlevsel olarak eksiksiz bir öğesi olarak anlaşılır. Tanım olarak, bir modül, belirtilen arabirimler mevcutsa, onu bir başkasıyla kolayca değiştirme olasılığını varsayar. Büyük ölçüde, sistemin modüllere bölünmesi, kullanılan işletim sistemi tasarım yöntemiyle belirlenir (aşağıdan yukarıya veya tam tersi).

Bir işletim sistemi kurarken özellikle önemli olan ayrıcalıklı, yeniden girişli ve yeniden girişli modüllerdir (yeniden giriş - kelimenin tam anlamıyla yeniden giriş; programın çalışabilirliği için özel bir terim; bir kesintiden özyinelemeli (geri dönen) bir çağrı yapıldığında programın doğru şekilde yürütülmesi özelliği).

Bu ilkenin kullanımından en büyük etki, bu ilkenin işletim sistemine, uygulama programlarına ve donanıma aynı anda dağıtılması durumunda elde edilebilir.

2.) Fonksiyonel seçicilik ilkesi- işletim sisteminde, bilgi işlem sürecinin daha verimli organizasyonu için sürekli olarak RAM'de olması gereken bazı önemli modüller tahsis edilmiştir. İşletim sisteminin bu bölümüne, sistemin temeli olduğu için çekirdek denir. Çekirdeğin bileşimini oluştururken iki çelişkili gereklilik dikkate alınmalıdır. Bir yandan, en sık kullanılan sistem modülleri çekirdeğe dahil edilmeli, diğer yandan modül sayısı, çekirdeğin kapladığı bellek miktarı çok fazla olmayacak şekilde olmalıdır. Çekirdeğin bir parçası olan ve kalıcı olarak RAM'de bulunan program modüllerine ek olarak, adı verilen başka birçok sistem programı modülü olabilir. taşıma. Transit program modülleri sadece gerektiğinde RAM'e yüklenir ve boş alan olmadığında diğer transit modülleri ile değiştirilebilir.

3.) İşletim sistemi oluşturma ilkesi: ilkenin özü, işletim sisteminin merkezi sistem kontrol programının (çekirdek ve RAM'de kalıcı olarak bulunan ana bileşenler) ilk sunumu için böyle bir yöntemin organizasyonu (seçimi), bu sistem denetimini yapılandırmayı mümkün kılmıştır. belirli bir bilgi işlem kompleksinin özel konfigürasyonuna ve çözülmesi gereken görev aralığına dayalı kısım. Bu prosedür, işletim sisteminin yeterince uzun bir çalışma süresinden önce nadiren gerçekleştirilir. Üretim süreci, sistemin yazılım yeteneklerinin ve makinenin konfigürasyonunun tanımlanmasına izin veren özel bir jeneratör programı ve bu program için karşılık gelen giriş dili kullanılarak gerçekleştirilir. Üretimin bir sonucu olarak, işletim sisteminin tam bir sürümü elde edilir. Oluşturulan işletim sistemi sürümü, sistem modüllerinin ve veri kümelerinin bir koleksiyonudur.

4.) İşlevsel artıklık ilkesi: Bu ilke, aynı işi farklı yollarla gerçekleştirme olasılığını dikkate alır. İşletim sistemi, çeşitli türde monitörler (bir veya başka bir tür kaynağı kontrol eden süpervizör modülleri), bilgi işlem süreçleri arasındaki iletişimi organize etmenin çeşitli yollarını içerebilir. Çeşitli monitör türlerinin varlığı, birkaç dosya yönetim sistemi, kullanıcıların işletim sistemini belirli bir bilgisayar sisteminin belirli bir yapılandırmasına hızlı ve en uygun şekilde uyarlamasına, belirli bir görev sınıfını çözerken donanımın en verimli şekilde yüklenmesini sağlamasına ve maksimum performans elde etmesine olanak tanır. belirli bir görev sınıfını çözerken.

5.) Sanallaştırma ilkesi: sanal kaynakların yapımı, dağıtımı ve kullanımı şu anda hemen hemen her işletim sisteminde kullanılmaktadır. Bu ilke, sistemin yapısını belirli bir dizi süreç planlayıcı ve kaynak dağıtıcısı (izleyici) şeklinde temsil etmeyi ve kaynakları dağıtmak için tek bir merkezi şema kullanmayı mümkün kılar.

Sanallık kavramının en doğal ve eksiksiz tezahürü, sanallık kavramıdır. sanal makine. Kullanıcıya sağlanan sanal makine, gerçek makinenin mimarisini yeniden üretir, ancak bu temsildeki mimari öğeler, kural olarak sistemle çalışmayı basitleştiren yeni veya geliştirilmiş özelliklerle görünür. Karakteristikler isteğe bağlı olabilir, ancak çoğu zaman kullanıcılar aşağıdaki kompozisyonda mimari özellikler açısından kendi "ideal" makinelerine sahip olmak isterler:

- neredeyse sınırsız hacimli sanal bellek, çalışma mantığı açısından tek tip.

- çalışma sırasında paralel olarak çalışabilen ve etkileşime girebilen isteğe bağlı sayıda sanal işlemci.

- bu cihazların çalışmasını başlatan şu veya bu sanal işlemcinin çalışmasına göre bir sanal makinenin belleğiyle paralel veya sıralı, eşzamansız veya eşzamanlı olarak çalışabilen isteğe bağlı sayıda harici sanal cihaz.

Sanallaştırmanın yönlerinden biri, diğer işletim sistemleri için geliştirilmiş uygulamaları bu işletim sisteminde yürütme olasılığının organizasyonudur. Başka bir deyişle, birden fazla çalışma ortamı düzenlemekten bahsediyoruz.

6.) Harici cihazlardan program bağımsızlığı ilkesi: bu ilke şu anda genel uygulama işletim sistemlerinin büyük çoğunluğunda uygulanmaktadır. İlk kez, bu ilke en tutarlı şekilde UNIX OS'de uygulandı. Ayrıca çoğu modern PC işletim sisteminde uygulanmaktadır. Bu ilke, programların belirli cihazlarla bağlantısının, programın yayınlanması düzeyinde değil, yürütülmesi için planlama döneminde gerçekleştirilmesi gerçeğinde yatmaktadır. Sonuç olarak, program verilerin bulunduğu yeni bir cihazla çalıştığında yeniden derleme gerekli değildir.

7.) Uyumluluk ilkesi: uyumluluğun bir yönü, işletim sisteminin diğer işletim sistemleri veya bu işletim sisteminin önceki sürümleri için ve ayrıca farklı bir donanım platformu için yazılmış programları çalıştırma yeteneğidir. soruları ayırmak lazım ikili uyumluluk ve kaynak düzeyinde uyumluluk uygulamalar.

Yürütülebilir bir programı alıp başka bir işletim sisteminde çalıştırabildiğinizde ikili uyumluluk elde edilir. Bu, işlemcinin talimat düzeyinde uyumluluk ve sistem çağrıları düzeyinde ve hatta dinamik olarak bağlanmışlarsa kitaplık çağrıları düzeyinde uyumluluk gerektirir.

Kaynak kodu düzeyinde uyumluluk, sistem yazılımında uygun bir çevirmenin bulunmasının yanı sıra kitaplıklar ve sistem çağrıları düzeyinde uyumluluğu gerektirir. Bu durumda, mevcut kaynak metinleri yeni bir yürütülebilir modülde yeniden derlemek gerekir.

Farklı mimarilere dayalı işlemciler arasında ikili uyumluluğu sağlamak çok daha zordur. Bir bilgisayarın diğerinin programlarını yürütebilmesi için (örneğin, IBM PC gibi bir PC için bir program, Apple Macintosh gibi bir PC'de çalıştırılması arzu edilir), bu bilgisayar, çalışmadığı makine talimatlarıyla çalışmalıdır. başta anlamak. Böyle bir durumda, 680x0 (veya PowerPC) tipi bir işlemci, bir i80x86 işlemciye yönelik ikili kodu yürütmelidir. 80x86 işlemcinin kendi talimat kod çözücüsü, kayıtları ve iç mimarisi vardır. 680x0 işlemci 80x86 ikili dosyasını anlamıyor, bu nedenle her talimatı getirmeli, olup olmadığını belirlemek için kodunu çözmeli.

neye yönelik olduğunu ve ardından 680x0 için yazılmış eşdeğer alt yordamını yürütün.

Program ve kullanıcı arayüzlerinin uyumluluğunu sağlamanın yollarından biri, kullanımı daha sonra bir sistemden diğerine kolayca taşınabilen UNIX tarzı programlar oluşturmanıza izin veren POSIX standartlarına uygunluktur.

8.) Açıklık ve genişletilebilirlik ilkesi: Hem kullanıcılar hem de bilgisayar sistemine hizmet veren sistem uzmanları tarafından analiz için açık bir işletim sistemi mevcuttur. Ölçeklenebilir (değiştirilebilir, gelişen) bir işletim sistemi, yalnızca üretim yeteneklerini kullanmakla kalmaz, aynı zamanda bileşimine yeni modüller eklemeye, mevcut olanları iyileştirmeye vb. Diğer bir deyişle, sistem bütünlüğünü bozmadan, gerektiğinde eklemeler ve değişiklikler kolayca yapılabilir olmalıdır. İşletim sistemini mikro çekirdek teknolojisini kullanan bir istemci-sunucu olarak yapılandırma yaklaşımı, genişleme için mükemmel fırsatlar sağlar. Bu yaklaşıma uygun olarak, işletim sistemi bir dizi ayrıcalıklı kontrol programı ve bir dizi ayrıcalıksız hizmet (sunucu) olarak inşa edilmiştir. İşletim sisteminin ana kısmı aynı kalır ve aynı zamanda yeni sunucular eklenebilir veya eskileri geliştirilebilir. Bu ilke bazen şu şekilde yorumlanır: sistem genişletilebilirliği.

9.) Hareketlilik ilkesi: işletim sisteminin aktarılması nispeten kolay olmalıdır

bir tür işlemciden başka bir tür işlemciye ve işlemci türüyle birlikte tüm bilgisayar donanımını (bilgisayar sistemi mimarisi) düzenleme yöntemini içeren bir tür donanım platformundan başka bir donanım platformuna tip. Aynı şey olmasalar da taşınabilirlik ilkesinin uyumluluk ilkesine çok yakın olduğunu unutmayın. Taşınabilir bir işletim sistemi oluşturmak, herhangi bir taşınabilir kod yazmaya benzer, ancak izlemeniz gereken birkaç şey var. tüzük:

- İşletim sisteminin çoğu, gelecekte aktarılmasının planlandığı tüm sistemlerde bulunan bir dilde yürütülmelidir. Bu öncelikle işletim sisteminin yüksek seviyeli bir dilde, tercihen C gibi standartlaştırılmış bir dilde yazılması gerektiği anlamına gelir. Birleştiricide yazılan bir program genellikle taşınabilir değildir.

- Kodun donanımla doğrudan etkileşime giren kısımlarını en aza indirmek veya mümkünse ortadan kaldırmak önemlidir. Donanım bağımlılığı birçok şekilde olabilir. Bazı bariz bağımlılık biçimleri, kayıtların ve diğer donanımların doğrudan manipülasyonunu içerir. Son olarak, donanıma bağlı kod tamamen ortadan kaldırılamıyorsa, birkaç iyi yerelleştirilmiş modülde izole edilmelidir. Donanıma özel kodun sistem genelinde dağıtılmasına gerek yoktur. Örneğin, bir soyut türdeki yazılım tanımlı verilerde cihaza özel bir yapıyı gizlemek mümkündür.

POSIX standartlarının tanıtılması, oluşturulan yazılımın taşınabilirliğini sağlamayı amaçlıyordu.

10.) Bilgi işlem güvenliği ilkesi: hesaplamalar yapılırken güvenlik sağlanması, herhangi bir çok kullanıcılı sistem için istenen bir özelliktir. Güvenlik kuralları, bir kullanıcının kaynaklarını diğerlerinden korumak ve bir kullanıcının bellek gibi tüm sistem kaynaklarını devralmasını önlemek için kaynak kotaları ayarlamak gibi özellikleri tanımlar.

Bilgilerin yetkisiz erişime karşı korunmasının sağlanması, ağ işletim sistemlerinin zorunlu bir işlevidir.

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

NePOSIX: bir bilgisayar ortamı için platformdan bağımsız sistem arayüzü POSIX (Bilgisayar Ortamları için Taşınabilir İşletim Sistemi Arayüzü), açık işletim sistemleri için sistem arayüzlerini tanımlayan bir IEEE standardıdır (Elektrik ve Elektronik Mühendisleri Enstitüsü - Elektrik ve Elektronik Mühendisleri Enstitüsü.), kabuklar, yardımcı programlar ve araç takımları. Ayrıca POSIX'e göre güvenlik görevleri, gerçek zamanlı görevler, idari süreçler, ağ işlevleri ve işlem işleme standartlaştırılmıştır. Standart, UNIX sistemlerini temel alır, ancak diğer işletim sistemlerinde uygulamaya izin verir. POSIX, dünyaca ünlü IEEE organizasyonunun, soyut, platformdan bağımsız bir standart geliştirerek UNIX ortamlarında uygulama taşınabilirliğini teşvik etme girişimi olarak ortaya çıkmıştır. Örneğin, iyi bilinen gerçek zamanlı işletim sistemi QNX, bu standardın özelliklerine uygundur.

Bu standart, sanal bellek sistemi VMS'yi (Sanal Bellek Sistemi), çok görevli MPE'yi (Multi-Process Executing) ve işletim sistemleri CTOS'u (Bir İşletim Sistemi Tarafından Üretilen Yakınsak Teknolojisi...) aktarma teknolojisini ayrıntılı olarak açıklar. Yani POSIX aslında POSIX.I'den POSIX.12'ye kadar adlandırılan bir standartlar dizisidir. Ayrıca POSIX.1'in birincil dil olarak C'yi varsaydığını da özellikle belirtmek gerekir.

API sistem işlevleri açıklama dili.

Böylece bu standartlara göre yazılan programlar tüm POSIX uyumlu sistemlerde aynı şekilde çalışacaktır. Ancak, bazı durumlarda standart, doğası gereği yalnızca tavsiye niteliğindedir. Bazı standartlar çok katı bir şekilde tanımlanırken, diğer kısım sadece temel gereksinimleri yüzeysel olarak ortaya koymaktadır.

POSIX API'nin işletim sistemi düzeyindeki uygulamaları farklıdır. UNIX sistemlerinin büyük çoğunluğu başlangıçta IEEE Standardı 1003.1-1990 belirtimlerine uyuyorsa, WinAPI POSIX uyumlu değildir. Ancak bu standardı desteklemek için MS Windows NT işletim sistemi, kullanıcı işlemlerinin ayrıcalık düzeyinde çalışan özel bir POSIX API destek modülünü tanıttı.

Bu modül, Win API aracılığıyla çekirdekle çalışarak, kullanıcı programından gelen çağrıların sistem çekirdeğine dönüştürülmesini ve aktarılmasını sağlar. WinAPI kullanılarak oluşturulan diğer uygulamalar, standart G/Ç akış mekanizmaları (stdin, stdout) aracılığıyla POSIX uygulamalarına bilgi aktarabilir.

Alakalı Gönderi Yok...

Genel olarak standartlar hakkında

Pratisyen programcılar arasında, programlamada standartların hiç gerekli olmadığına dair bir görüş vardır, çünkü:

(1) yazarları bilgisayar programları yazmadığından başlangıçta anlamsızdırlar;

(2) programcıların inisiyatifini kısıtlarlar;

(3) programcılar her zaman standartlar olmadan hemfikir olacaktır.

Belki de bu görüş, iki durumda olmasa bile dikkate alınmamalıydı:

(1) uygulayıcılar, yani tam olarak “yazılım ürünleri yayınlayanlar” tarafından ifade edilir;

(2) yukarıdaki akıl yürütme, bu makalenin yazarı tarafından, C programlama dili standardına ayrılmış İnternet yayınlarından birinde bulundu; bu, böyle bir görüşün "uluslararası ölçekte" yaygın olduğu ve sadece kibirli Rus "süper programcılar" arasında.

“Standart” kelimesi genellikle maddi bir şeyle (standart boyutlar, standart elektrik voltajı vb.) ilişkilendirilirken, bir bilgisayar programı maddi olmayan bir nesnedir (“Yeni maddi olmayan”) ve belki de maddi olmayan alandaki standartlar gerçekten anlamsız mı?

Ancak çürüten bir örnek var. Rus dilinin yazım kuralları seti, standardizasyon kuruluşları tarafından onaylanmamasına rağmen, esasen bir standarttır. Ayrıca, yazım kurallarına (veya isterseniz gereksinimlerine) ek olarak, sözdizimsel kurallar ve en önemlisi anlambilim vardır. İkincisi, “çocukça” soruyu iyi bir şekilde göstermektedir: bir kediye neden kedi denir? Bu sorunun kesin bir cevabı var: çünkü atalarımız da aynı fikirde; İngilizlerin ataları, aynı hayvan kedisini, Almanların atalarını - yavru kedi, vb. Ve genel olarak, herhangi bir kelimenin veya kelime kombinasyonunun anlamı veya semantiği veya yorumlanması için kurallar bir anlaşma meselesidir.

POSIX standardının amacı ve "süper görevi"

Adından da anlaşılacağı gibi, POSIX (Taşınabilir İşletim Sistemi Arayüzü), bir işletim sistemi ile bir uygulama programı arasındaki arayüz (arayüz) için bir standarttır. Programcıların "çıplak" bir makine için programlar yazdığı zamanlar (kendi G/Ç paketlerini, trigonometrik işlevleri vb. uygulamak) sonsuza dek gitti. POSIX metni, standardın işletim sistemi uygulama ayrıntıları üzerinde hiçbir talepte bulunmadığını tekrar tekrar vurgular; uygulama programcıları ve işletim sistemi geliştiricileri arasındaki bir dizi anlaşma olarak düşünülebilir. Bu nedenle (yine, oldukça yaygın bir inancın aksine), POSIX yalnızca işletim sistemi geliştiricileri için değil, aynı zamanda öncelikle çok daha geniş bir programcı kategorisi - uygulama programcıları için de ilgi çekicidir.

Bu tür bir standarda duyulan ihtiyaç, UNIX işletim sistemlerinin yaygınlaştığı 1980'lerde fark edildi. Bu sistem birleşik olarak tasarlanmasına rağmen, belirli uygulamaları arasındaki farklılıklar, bir sistem için yazılan uygulama programlarının her zaman başka bir sistemde yürütülemeyeceği gerçeğine yol açtı. POSIX'in çözmeyi amaçladığı, yazılım taşınabilirliği sorunu olarak bilinen tam da bu sorundur. Standardın ilk baskısı 1988'de yayınlandı (çeviri mevcuttur, bakınız), program taşınabilirliği ile ilgili tüm çeşitli konuların iki bölüme ayrıldığı: (1) uygulama programı arayüzü, (2) komut yorumlayıcısı ve yardımcı programlar (kullanıcı arayüzü); bu bölümler sırasıyla POSIX.1 ve POSIX.2 olarak adlandırılır.

Açıklığa kavuşturmak için, bu makale yalnızca ikinci (ve bugüne kadar) baskısı 12 Temmuz 1996'da onaylanan uygulama programı arabirim standardı POSIX.1'e odaklanacaktır.

Standardın bilgilendirici kısmı ayrıca POSIX'in bazı "ideal" işletim sistemlerinin arayüzünün bir tanımı olmadığını, UNIX işletim sistemlerinin geliştirilmesinde kazanılan deneyimlerin genelleştirilmesi ve sistemleştirilmesinin bir sonucu olduğunu vurgular. Ek olarak, bilgilendirici bölüm programcılar ve program parçacıkları için öneriler içermesine rağmen, POSIX işletim sistemleri hakkında bir kılavuz veya öğretici olarak hizmet etmek için tasarlanmamıştır.

Standart, yalnızca içinde açıklanan arayüz işlevlerine odaklanarak tam teşekküllü bir işletim sistemi oluşturmanın imkansız olduğunu doğrudan belirtir. (Özellikle, POSIX.1, ağ oluşturma ve ilgili arabirim işlevleri veya bir grafik kullanıcı arabirimi gibi sorunları ele almaz.) Ancak, taşınabilir olmayan programların mali maliyeti ve sonuçta ortaya çıkan arabirim birleştirme ihtiyacı, çoğu satıcının tercih ettiği kadar büyüktür. hiç olmamasından daha az bir standardı vardır. Bu nedenle birçok yazılım geliştiricisi POSIX'e odaklanma eğilimindedir. Bu, programların hareketliliğini tamamen ortadan kaldırmasa bile, programın mobil olmayan kısmını en azından önemli ölçüde azaltır.

anlambilim hakkında

Daha önce de belirtildiği gibi, POSIX, bir işletim sistemi tasarımcısı ile bir uygulama programcısı arasındaki bir dizi anlaşma olarak düşünülebilir. "Anlaşma", her şeyden önce, kelimelerin ve ifadelerin aynı yorumu (anlambilimi) anlamına gelir. Aşağıdakiler, bir "anlaşmaya" ulaşmanın zorluğunu gösteren örneklerdir.

Çeviride anlam nasıl aktarılır

Her şeyden önce, POSIX standardının İngilizce olarak yazıldığını, doğası gereği belirsizliklere neden olduğunu (örneğin, aynı kelime bir isim, sıfat ve fiil olabilir) ve “anlamsal tuzakların” pusuda beklediğini hatırlamak gerekir. neredeyse her sayfada. Söylenenlerin iyi bir örneği kurgudan bir örnektir. İngiliz dilinin bu özelliğini ustaca kullanan Oscar Wilde'ın en ünlü eserlerinden biri olan - Ciddi Olmanın Önemi - Rusça'da "Ciddi Olmanın Önemi" başlığıyla bilinir. Bununla birlikte, İngilizce adının ikinci bir anlamı vardır: Earnest (ciddi), karakterlerden birinin soyadıdır ve isim farklı şekilde çevrilebilir: "Ernst olmak ne kadar önemli." Bir Rus soyadı Serebryany var ve bir soyadı Serezny olsaydı, her iki anlamın da aktarılmasıyla çeviri tamamen doğru olurdu.

Durum, standardın adıyla benzer: Taşınabilir İşletim Sistemi Arayüzü. Portable (mobil) sıfatı hem işletim sistemini hem de uygulama programını ifade eder, ancak Rusça'da bu kadar kısaca ifade edilemez, “Mobil işletim sistemi arayüzü” veya “Uygulamanın hareketliliğini sağlayan işletim sistemi arayüzü” olarak tercüme edilebilir. programları”. İkinci seçenek, standardın geliştiricilerinin niyetlerini daha iyi yansıtır, ancak ilk anlam kaybolur (çeviride daha tanıdık olan ilk seçenek korunmuştur).

"Standart" kelimesinin anlamı

Standardın ana metni, IEEE Standartları2 kelimelerinin anlamlarını açıklayan bir önsözden önce gelir. Bu açıklamalardan anlaşılacağı gibi, Rusça GOST teriminden en az üç anlamsal farklılık vardır:

(1) Sezgisel olarak, GOST'un ihlali kovuşturulan yasa gücüne sahip olduğuna inanılmaktadır; POSIX, uyulması tamamen gönüllü olan bir dizi gereksinimdir.

(2) GOST iptal edilene kadar geçerlidir (birçoğu muhtemelen “GOST kimse tarafından iptal edilmedi” ifadesini duymuştur); POSIX'in önsözü, standart 5 yıl boyunca revize edilmemişse, bunun içinde ele alınan konuların büyük olasılıkla artık alakalı olmadığı ve otomatik olarak iptal edilmiş sayılabileceği anlamına gelir;

(3) GOST anonimdir; POSIX'in giriş kısmı, bu standardın geliştirilmesine katkıda bulunan kişilerin bir listesini ve ayrıca yorum taleplerinin gönderilebileceği adresi sağlar; Ayrıca her talebe verilen yanıtın bir müzakere prosedürüne tabi olduğu söylenir (başka bir deyişle, standardın yazarları bir yanıt vermeden önce kendi aralarında anlaşırlar).

Bu nedenle, Standard gibi iyi bilinen bir kelimenin bile "standart" kelimesiyle çevirisi yorum gerektirir.

"Should", "belirtilmemiş", "tanımlanmamış", "uygulama tanımlı" kelimelerinin anlamı

Standardın 2. Bölümü "Terminoloji ve Genel Gereklilikler" başlığını taşımaktadır. Yalnızca teknik terimlerin ("süreç" veya "semafor" gibi) tanımlarını değil, aynı zamanda "gerekir" veya "olabilir" gibi görünüşte aşikar sözcükleri de içerir. POSIX.1 bir arabirim standardı olduğundan, gereksinimleri hem işletim sistemi hem de uygulama programı için geçerlidir. Açık bir gereksinim "yapacak" (yapacak) kelimesiyle ifade edilir, örneğin: "Başarılıysa, link() işlevi sıfır döndürmelidir." Bu örnekte, işletim sistemi için bir gereksinimden bahsediyoruz: link() işlevi, başarılı olduğunda sıfır döndürecek şekilde uygulanmalıdır.

"Belirtilmemiş" ve "tanımlanmamış" terimleri, standardın seçim özgürlüğüne izin verdiği fikrini ifade eder, ancak terimlerin anlamı farklıdır. "Belirtilmemiş" terimi, bazı doğrulardan (eylemler, program yapıları, vb.) ve "tanımlanmamış" teriminden - yanlış (hatalı) hakkında konuştuğumuz anlamına gelir. Standardın bilgilendirici kısmı aşağıdaki açıklamayı sağlar.

"Belirtilmemiş" terimi, seçenekler kümesinin (sonuçlar, bir işlev çağrısının sonuçları, vb.) bilindiği varsayılır ve standart bunlardan herhangi birine izin verir; işletim sisteminin belirli bir uygulamasında herhangi biri seçilebilir ve böyle bir sistemin standarda uygun olduğu kabul edilir. Başvuru programı (standartlara kesinlikle uygun) her halükarda doğru çalışacak şekilde yazılmalıdır; özünde, bu terim örtük olarak bir uygulama programı için bir gerekliliği ifade eder.

İşte bir örnek: “readdir() işlevi, dizinin bir sonraki öğesine atıfta bulunan bir yapıya bir işaretçi döndürmelidir. "nokta" ve "nokta - nokta" adlı dizin girişlerinin döndürülüp döndürülmediği standart tarafından belirtilmemiştir. Bu örnekte, dört sonuç mümkündür ve uygulamanın gereksinimi, bunlardan herhangi biri için tasarlanmış olmasıdır.

Başka bir örnek: “Belirtilen sayıya sahip bir sinyali bekleme talimatı veren sigwait() işlevi, birkaç kontrol iş parçacığında çağrılırsa, o zaman bunlardan birden fazlasına bir sinyal ulaşmadığında, sigwait() geri dönmelidir. Bunun hangi kontrol akışında olacağı standart tarafından belirtilmemiştir. Bu örnekte, olası sonuçlar kümesi daha büyük olabilir, ancak hepsi de bilinmektedir ve başvuru programının şartı, herhangi bir sonuç için doğru çalışması gerektiğidir.

"Tanımsız" terimi, bir dizi sonuç bilinmese bile, herhangi bir sonucun mümkün, hatta içler acısı (örneğin, sistem çökmesi, veri kaybı, vb.) anlamına gelir. Özünde, bu terim, uygulama programının ilgili verileri veya yapıları kullanmaması gerekliliğini dolaylı olarak ifade eder. Örneğin: "readdir() işlevinin dirp argümanı o anda açık olan dizine atıfta bulunmuyorsa, sonuç tanımsızdır."

Bu örnek, uygulamanın readdir() işlevine bir argüman olarak yalnızca açık bir dizine bir başvuru sağlamasını gerektirir; bu şartın ihlali feci sonuçlara yol açabilir ve bundan uygulama programcısı sorumludur.

İşte başka bir örnek: “Başarılı olursa, read() işlevi gerçekte okunan bayt sayısını gösteren bir tamsayı döndürmelidir. Aksi takdirde, işlev errno'yu bir hata koduna ayarlamalı ve arabelleğin içeriği tanımsız arabellek bağımsız değişkeni tarafından işaret edilerek -1 döndürmelidir."

Read() işlevinde bir hata olması durumunda uygulama programında arabellekten verilerin kullanılması standart tarafından yasaklanmıştır ve bu gereksinimin ihlalinin sonuçları uygulama programcısına yüklenir.

"Uygulama tanımlı" teriminin anlamı sezgisel değildir. Açıkçası, belirli bir işletim sisteminde “belirtilmemiş” veya “tanımsız” bir sonuç olamaz, mutlaka belirli bir sonuç elde edilecektir. "Uygulama tanımlı" terimi, işletim sistemi dokümantasyonu için standardın gerekliliğini ifade eder: sonuç sadece belirtilmemeli (işletim sistemi geliştiricisi bunu zaten yapmak zorunda kalacaktır), aynı zamanda sistem dokümantasyonuna da açıkça yansıtılmalıdır.

Varsayılan Semantik

Hiçbir düzenleyici belge, uygulamada meydana gelebilecek tüm durumları kapsayamaz, bu nedenle kaçınılmaz olarak bir şey hakkında sessiz kalır3. Örneğin bir fonksiyon açıklaması, argümanının belirli bir aralıktan değerler alabileceğini söyleyebilir, ancak argüman bu aralığın içine girmezse sonucun ne olacağını söylemez. Açıkçası, yanlış anlamaları önlemek için tek bir varsayılan anlambilime sahip olmak gerekir. Standardın bilgilendirici bölümünde ilginç bir ifade var: "varsayılanın genel olarak kabul edilen semantiği yasaktır." Bu açıklama, on yıllık meşhur sloganla çelişiyor: "Açıkça yasaklanmayan her şeye izin verilir." Görünüşe göre, vatandaşların zihnine o kadar yerleşmiş ki, çoğu programcı bile, standardın belirtilen ifadesine katılmıyor. Bu arada, herhangi bir yapının kullanımına açıkça izin verilmiyorsa ve açıklamanın sonucu değilse, o zaman herhangi bir uygulamalı programcı, onu kullanmanın riskli olduğunun farkındadır ve işe yaramazsa, iddiada bulunmak onun aklına gelmez.

Süreçler ve kontrol akışları

Bu terimlerin her ikisi de paralel yürütme fikrini ifade eder. UNIX işletim sistemi başlangıçta çok kullanıcılı bir işletim sistemi olarak tasarlandı ve farklı kullanıcılar tarafından çalıştırılan programlar, yanlışlıkla "yabancı" verileri bozmamak için birbirinden güvenli bir şekilde izole edilmelidir. Bu izolasyon, kullanıcı programının kendi sanal adres alanında gelişen bir süreç içerisinde yürütülmesi ile sağlanmaktadır. Program global veriye sahip olsa bile, farklı süreçlerde başlatıldığında, bunlar otomatik olarak farklı adres alanlarına "boşanacaktır".

Bununla birlikte, gerçek zamanlı görevler programlanırken süreçlerin mekanizması tamamen tatmin edici değildir. Gerçek zamanlı bir uygulama (aynı kullanıcı olarak çalışan) genellikle doğal olarak "iş parçacığı" adı verilen paralel çalışan parçalar olarak temsil edilebilir. Süreçlerden en önemli farkı, tüm kontrol akışlarının tek bir adres alanında gelişmesidir; bu, küresel verilere hızlı erişim sağlar, ancak aynı zamanda bunların yanlışlıkla bozulma riski vardır ve bunun olmasını önlemek için bazı programlama disiplinlerine uyulmalıdır. İlgili tavsiyeler standardın bilgilendirici bölümünde yer almaktadır.

Çoklu iş parçacığı fikrinin birçok gerçek zamanlı işletim sisteminde uygulandığı ve her bir kontrol iş parçacığına karşılık gelen farklı öznitelik kümeleri ve arayüz işlevleri anlamında farklı şekilde uygulandığı vurgulanmalıdır; bazen "kontrol akışı" (iş parçacığı) terimi yerine "görev" terimi kullanılır. Karışıklığı önlemek için standart, yalnızca POSIX kontrol iş parçacıklarıyla ilgilendiğini ve karşılık gelen arabirim işlevlerinin adlarının önüne pthread_ eklendiğini vurgular (örneğin, pthread_create(), pthread_join(), vb.).

Standarda uygunluk. "Karşılık gelir" kelimesinin anlamı

Sezgisel olarak, iki ürün aynı standartta yapılırsa, birbirleriyle "eşleşmeleri" ve bir çift olarak birlikte çalışmaları garanti edilir; bu tam olarak bir konjugasyon (arayüz) için bir standart getirmenin amacıdır. POSIX bir arayüz standardı olduğu için hem işletim sisteminin hem de uygulama programının standarda uygun olduğu söylenebilir.

POSIX.1 standardı birkaç yüz (binlerce değilse) gereksinim içerir; Bunlardan en az birinin yerine getirilmemesi durumunda sistemin (veya uygulama programının) standardı karşılamadığı aşikar kabul edilir. Aynı zamanda bugüne kadar o kadar çok UNIX sınıfı işletim sistemi ve uygulama programı yazılmıştır ki, bu anlamda tam uyumluluk talep etmek pek makul değildir. Bu tür bir uluslararası standart geliştirmenin zorlukları, farklı ulusal dillerin varlığıyla daha da kötüleşir. Ulusal dillerdeki metinleri işlemek için tasarlanmış uygulama programlarını unutsak bile, hemen hemen her uygulama programı bir tür teşhis mesajı yayınlamalı ve / veya operatör tarafından girilen metinleri kabul etmelidir.

• POSIX.1 standardına sıkı uyum;
• POSIX.1'in uluslararası sürümüyle uyumluluk;
• POSIX.1'in ulusal versiyonuna uygunluk;
• Uzantılarla POSIX.1 uyumluluğu.

İkinci olarak, birçok arayüz olanağı isteğe bağlı olarak bildirilir; Standart, isteğe bağlı arabirim işlevlerinin standart tarafından belirtildiği gibi çalışmasını veya her zaman özel bir hata kodu olan ENOSYS (işlev uygulanmadığı anlamına gelir) döndürmesini gerektirir. İsteğe bağlı araçlar, her biri ilgili başlık dosyasında bildirilen (#define ifadesi kullanılarak) bazı yapılandırma sabitlerine karşılık gelen birkaç gruba ayrılır; bu, derleme zamanında bir işlevin uygulanıp uygulanmadığını bulmayı mümkün kılar.

Hareketliliği elde etmek için açıklanan teknik, POSIX'in yazarları tarafından icat edilmedi, ancak pratikte uzun süredir kullanılmaktadır; birçok işletim sistemi, sistemin kendisini veya sürümünü tanımlamak için yapılandırma sabitlerini kullanır. Ve burada standart temelde yeni bir şey sunmuyor, sadece yerleşik uygulamayı sistematize ediyor.

Standardizasyon nesneleri ve standardın yapısı

Kısacası, POSIX.1 standardizasyonunun nesneleri isimler ve anlambilimdir. Daha spesifik olarak, aşağıdakilerden bahsediyoruz.

• Arayüz fonksiyonlarının isimleri. Standart C kitaplıklarından (matematik, dizi işleme, giriş/çıkış, vb.) alınan 107 işlev ile 357 işlev standartlaştırılmıştır; bu işlevler POSIX.1 standardının bir parçası olarak kabul edilir, ancak C programlama dili standardında tam olarak açıklanmıştır.
• Sistem veri türlerinin adları. Bu adların bir _t son eki vardır.
• Başlık dosyalarının adları ve bu dosyaların minimum bileşimi.
• Sistem çapında global değişkenlerin adları (örneğin, errno).
• İşlev işleme sırasında ayarlanabilen hata kodlarının sembolik adları. Bu isimler E harfi ile başlar (EPERM, ENOTEMPTY, vb.).
• Yapılandırma sabitlerinin adları. Bu adların önüne _POSIX_ eklenir.
• Sinyal numaralarının sembolik isimleri; bu adların önüne SIG eklenir. 20 "geleneksel" sinyale (SIGABRT, SIGALRM, vb.) ek olarak, sayıları SIGRTMIN'den SIGRTMAX'e kadar en az RTSIG_MAX sayıları içeren belirli bir sürekli aralığı kapsaması gereken gerçek zamanlı sinyaller standartlaştırılmıştır.
• Bazı fonksiyonların bireysel argümanlarının değerlerine karşılık gelen sembolik isimler (örneğin, fcntl() fonksiyonunun cmd argümanı F_DUPFD, F_GETFD, F_GETLK, vb. değerleri alabilir).
• Makroların, sabitlerin, bit bayraklarının, ortam değişkenlerinin adları.

Genel olarak standart, yaklaşık olarak aynı hacme sahip iki büyük parçadan oluşur. İlk yarı - normatif kısım - standardın gerekliliklerini ve tavsiyelerini içerir (18 bölüm), ikincisi - bilgilendirici kısım - normatif kısma referansların, yorumların ve açıklamaların bir listesini sağlayan Ekleri, kompozisyonun bileşimini içerir. başlık dosyaları, standardın (Danimarka için) bir profilinin ("projeksiyon") bir örneği, en önemli işlevlerin performansını ölçmek için özellikler ve yöntemler ve ayrıca dosyalarla gerçek olarak çalışmak için ek arayüz işlevlerinin açıklaması zaman; standardın gelecekteki revizyonlarının bu işlevleri normatif kısma dahil etmesi beklenmektedir.

Hangi işletim sistemi hizmetlerinin standardın kapsadığı hakkında bir fikir için "Standart Bölümlerinin Özeti" kenar çubuğuna bakın.

Çözüm

POSIX standardının ana içeriği, arayüz fonksiyonlarının semantiğidir. Semantiğin standardizasyonu kendi başına kolay bir iş değildir (herkes iki kişinin bile aynı fikirde olmasının ne kadar zor olduğunu bilir) ve şu anda birçok insanın programlamaya dahil olması, zorlukları daha da kötüleştirmektedir. Örneğin, paralel yürütme paradigması "süreç", "görev" ve "kontrol akışı" gibi terimlerle ifade edilir, ancak pratik programlama açısından "görev" IBM OS / 360 işletim sisteminde ve VxWorks gerçek zamanlı işletim sistemi hiç de aynı değildir ve ayrıca. Başka bir örnek semaforlardır. Semaforlar ikili, tamsayı ("bir sayaçlı") ve karşılıklı dışlamadır (bu arada, programcılar kendi aralarında "mutex" derler, kendiliğinden yanlış anlamaları önlemeye çalışırlar). Ve örneğin VxWorks işletim sistemindeki tamsayı semaforları, POSIX semaforlarıyla hiç de aynı değildir.

POSIX standardının yazarları, insanların alışkanlıklarını ("yerleşik uygulama" olarak adlandırdıkları) bırakmalarının ne kadar zor olduğunun çok iyi farkındadırlar, mantıksal olarak tutarlı ve minimal bir arayüz fonksiyonları sistemi derlediklerini iddia ederler. Geleneksel olarak işletim sistemi tarafından sağlanan hizmetler, bu işlevlerin tam anlamını ayrıntılı olarak açıklar ve herkesi geliştirmelerinde kullanmaya davet eder4.

Standardı okurken bazen bazı ifadelerin tek amacının bazı uygulama programlarını veya işletim sistemlerini standarda uygunluk kategorisinden düşürmemek olduğu izlenimi edinilir. Böyle bir hedef gerçekten Giriş'te belirlendi ve açıkça formüle edildi: standart, geçerli uygulamayı mümkün olan en yüksek ölçüde hesaba katmalıdır. Ancak yine de asıl amaç uygulama programlarının hareketliliğini sağlamaktır.

Yazar hakkında

Sergey Romanyuk - Sistem Araştırmaları Araştırma Enstitüsü Kıdemli Araştırma Görevlisi, POSIX Standard Translator Group Başkanı. Şu adresten e-posta ile iletişime geçilebilir: [e-posta korumalı]

1 Standarda yönelik çalışmaların uzun yıllardır devam ettiğini de eklemek gerekir; yeni sorular belirlenir ve bunlar ya mevcut bölümlerden birine dahil edilir ya da daha sonra iptal edilebilecek ayrı bir bölüm olarak yayınlanır. Bu, örneğin, ilk olarak POSIX.4 olarak ilan edilen ve daha sonra POSIX.1'e dahil edilen gerçek zamanlı arayüz olanakları ile oldu.

2 IEEE, POSIX standardını geliştiren kuruluştur.

3 Burada "varsayılan" varsayılan değil sessiz anlamına gelir; aslında beyan edilen bazı zımni değerlerden değil, hiç bahsedilmemesinden bahsediyoruz.

4 Standardın Rusça çevirisi 2000 yılının başlarında yayınlanacaktır.

Edebiyat

Uluslararası Standart ISO/IEC 9945-1 (ANSI/IEEE Std 1003.1) İkinci Baskı. 1996-07-12. Bilgi Teknolojisi - Taşınabilir İşletim Sistemi Arayüzü (POSIX) - Bölüm 1: Sistem Uygulama Programı Arayüzü (API).

M.I.Belyakov, Yu.I.Rabover, A.L.Friedman. mobil işletim sistemi. Dizin. Moskova, Radyo ve İletişim, 1991.

ISO/IEC 9899: 1990, Programlama dilleri - C.

Bölüm 1	- Giriiş
Bölüm 2	- Terminoloji ve tanımlar
3. Bölüm	- Süreçleri (görüntü oluşturma, değiştirme, sonlandırma) ve sinyalleri (maskeleri yönetme, sinyallere yanıt verme) yönetme işlevleri
Bölüm 4	- Tanımlama (süreçler, kullanıcılar, sistem, terminal), işlemin yürütülmesi için harcanan yoklama süresi, yoklama ortam değişkenleri.
5. Bölüm	- Dosyaları ve dizinleri yönetin
6. Bölüm	- Giriş ve çıkış fonksiyonları
Bölüm 7	- Terminal yönetim fonksiyonları
Bölüm 8	- C standardından ödünç alınan fonksiyonlar
9. Bölüm	- Kullanıcıların ve kullanıcı gruplarının veritabanlarına erişim
Bölüm 10	- Arşivleme ve değişim için veri biçimleri (tar ve cpio)
11. Bölüm	- Senkronizasyon araçları: semaforlar, muteksler ve koşul değişkenleri
Bölüm 12	- Bellek yönetimi özellikleri: işlem adres alanını sabitleme ve sabitlemeyi kaldırma, bellek dosyası eşleme, bellek koruması, paylaşılan bellek
13. Bölüm	- Zamanlama süreçleri ve kontrol akışlarıyla ilgili işlevler
Bölüm 14	- Saatleri ve zamanlayıcıları yönetin
Bölüm 15	- Mesaj kuyruklarını yönetme
Bölüm 16	- Kontrol akışlarıyla ilgili temel işlevler
Bölüm 17	- Bireysel iş parçacığına özgü veriler
18. Bölüm	- Kontrol akışı imha araçları

POSIX (taşınabilir işletim sistemi arabirimi), bir işletim sistemi ile bir uygulama programı arasındaki arabirimi tanımlayan bir standarttır. Bu standardın oluşturulmasındaki amaç, unix benzeri işletim sistemlerinin uyumluluğunun yanı sıra programların kaynak kod düzeyinde taşınabilirliğini sağlamaktır. Ancak POSIX standardı sadece unix sistemleri tarafından kullanılamaz. POSIX adı Richard Stallman tarafından önerildi. Belirgin "pozix", taşınabilir Unix işletim sistemlerinin arabirimidir.

biraz tarih

POSIX standardının ilk versiyonu IEEE Std 1003 idi. 1988'de yayınlandı ve C programlama dili ile unix benzeri sistemlerin çekirdek kabuğu arasındaki arayüzü tanımladı.

1990 yılında, IEEE Std 1003.2'nin yeni bir sürümü yayınlandı. İlk versiyona kıyasla, yeni belgede küçük değişiklikler yapıldı.

1992'de iki ciltlik IEEE Std 1003.2 standardı yayınlandı. Belge, komut yorumlayıcısını ve yüzden fazla yardımcı programı tanımladı.

1993 yılında piyasaya sürülen bir sonraki sürüm, önceki sürümlere küçük bir ekti: dosya senkronizasyonu, semaforlar, zaman ayarları, zamanlayıcı, mesaj kuyruğu, asenkron G / Ç hakkında bilgiler vardı.

1995'te, iş parçacığına özgü başka bir standart yayınlandı ve 1996 sürüm belgesi, önceki sürümlere bir tür ek oldu.

1999 POSIX standardı, ek gerçek zamanlı uzantıları tanımladı.

2001 yılında, önceki tüm sürümleri birleştiren bir standart yayınlandı. Gelecekte standartların benimsenmesi için bir temel olarak kullanılmasına karar verildi.

2008 yılında onaylanan POSIX.1 sürümü şu anda kullanımda.

POSIX standardının temel fikirleri

Belgelenmiş hükümlere göre, uygulamalarla doğru etkileşim için işletim sistemi aşağıdaki bileşenlere sahip olmalıdır:

• ağ tesisleri;
• Geliştirme araçları;
• kontrol akışları;
• gerçek zamanlı araçlar;
• paket hizmetler;
• başlık dosyaları;
• matematiksel arayüzler;
• eski arayüzler

POSIX standartlarına uygun işletim sistemlerinin özellikleri

• ayrıcalıklı haklara sahip kök süper kullanıcının yanı sıra kullanıcı ve grupların haklarının farklılaştırılması;
• tek bir kökü olan ağaç benzeri bir dosya sisteminin varlığı /;
• sistem ve yazılım paketleri metin dosyaları olarak sağlanır - yani dosya yapılandırmaları basit düzenleme ile değiştirilebilir;
• birleşik C programlama API'si;
• konsol yardımcı programları ve komutları için tek bir standart (POSIX 2).

POSIX standardına göre sertifikalandırılmış işletim sistemleri şunları içerir: IBM AIX, UnixWare, Solaris, IRIX, QNX, LynxOS, Mac OS X. POSIX standardının sürümlerinden biri ile tam uyumlu, Minix, BSD'nin çeşitli dalları, OpenSolaris, VxWorks, OpenWMS . Linux dağıtımlarına gelince, çoğu, sırayla POSIX'e dayanan LSB (Linux Standard Base) standardına uygundur.

2003 POSIX standardı, aşağıdaki sistem bileşeni kategorilerini ayrıntılandıran çok kapsamlı, çok yönlü bir belgedir:

Geliştirme araçları;

ağ tesisleri;

gerçek zamanlı araçlar;

kontrol akışları;

matematiksel arayüzler;

paket hizmetler;

başlık dosyaları;

eski arayüzler

Uygulamanın çalışması için işletim sisteminin sağlaması gereken (en üst düzeyde, tam olmaktan uzak) repertuar budur.

En önemlisi POSIX standardına uygunluk kavramıdır. Her arayüzün iki tarafı olduğunu belirtmiştik: arama ve arama. POSIX uyumluluğunun ayrıca iki yönü vardır: uygulama (işletim sistemi) uyumluluğu ve uygulama uyumluluğu.

POSIX standardına uygun bir uygulama (işletim sistemi), standartta belirtilen davranışı korurken gerekli tüm yardımcı programları, işlevleri, başlık dosyalarını desteklemelidir. _POSIX_VERSION sabiti 200112L değerine sahiptir.

İşletim sistemi, standartta isteğe bağlı olarak işaretlenen özelliklerin yanı sıra standart dışı özellikler de içerebilir. Bir uzantının desteklendiği iddia ediliyorsa, bu, gerekli tüm parçalar için tutarlı bir şekilde ve standartta açıklanan şekilde yapılmalıdır.

Başlık dosyasında desteklenen isteğe bağlı özelliklere karşılık gelen sabitleri tanımlamanız gerekir (örneğin, _POSIX2_C_DEV sabiti C geliştirme araçlarını sağlar). Uygulama, bu sabitleri derleme zamanında analiz ederek, kullanılan işletim sisteminin yeteneklerini anlayacak ve bunlara göre ayarlayacaktır. Benzer çalışma zamanı eylemleri, sysconf() işlevi ve/veya getconf yardımcı programı kullanılarak gerçekleştirilebilir.

İşletim sisteminin ve uygulamaların boyutunu en aza indirmek için POSIX standardı, isteğe bağlı özelliklerin (toplamda kırk) çok ince bir ayrıntı düzeyi sağlar. Öte yandan, birbiriyle ilişkili isteğe bağlı özellikler, birçok durumda çok sayıda seçeneği analiz etme ihtiyacını ortadan kaldıran gruplar halinde birleştirilmiştir. Bu gruplar:

şifreleme;

gerçek zamanlı araçlar;

gelişmiş gerçek zamanlı araçlar;

gerçek zamanlı akışlar;

gelişmiş gerçek zamanlı akışlar;

izleme;

• eski yetenekler.

Örneğin, "gerçek zamanlı araçlar" (_XOPEN_REALTIME) grubu, öncelik tabanlı zamanlama, eşzamansız G/Ç, semaforlar, zamanlayıcılar vb. dahil olmak üzere on dört tür yetenek içerir.

Bu dersin metninin hazırlandığı Linux işletim sistemi sürümü, bazı yapılandırma sabitleri için aşağıdaki değerleri üretti (bkz. liste 1.1).

$ getconf _POSIX_VERSION

$ getconf POSIX2_C_DEV

$ getconf _XOPEN_REALTIME

$ getconf _POSIX_TRACE

Liste 1.1. Getconf yardımcı programının Linux işletim sistemi sürümlerinden birine uygulanmasının sonucu. ( html, Txt)

Bu, POSIX standardının eski bir sürümünün desteklendiği, geliştirme araçlarının ve gerçek zamanlı yeteneklerin diğerleri arasında mevcut olduğu anlamına gelir; izciler yok.

İşletim sistemi belgeleri, POSIX standardına uygunluk sorunlarını yansıtmalı, desteklenen ek ve standart dışı özellikleri açıklamalıdır.

Uygulamalar için, POSIX uyumluluğu kavramı daha nüanslıdır. Temel ayırt edici özelliği, standart çerçevesinde kullanılan özellik yelpazesinin sınırlandırılması olan katı uyum sağlanır. Uzantıların kullanımına uygunluk da dikkate alınır; bu durumda, uygulama belgeleri gerekli standart dışı özelliklerin bir tanımını içermelidir. Kullanılan POSIX özellik uzantılarının uluslararası ve/veya ulusal standartlarla açıklanması arzu edilir.

(Yalnızca yönetimsel araçlar olmadan işletim sistemleri olmadığı ve bu standart tarafından tanımlanmadıkları için katı POSIX uyumluluğu kavramının bir uygulama için anlamsız olduğunu unutmayın.)

Profil, isteğe bağlı özellikleri tanımlayan bir dizi seçenektir. Bir profile uygunluk, POSIX standardına uygunluk ve belirtilen yetenekler için destek anlamına gelir. Düzgün seçilmiş profiller, temsili kullanıcı ve/veya uygulama sınıflarının ihtiyaçlarını karşılar.

"Alt profillerin" standart yeteneklerin alt kümelerini tanımlamasına izin verilir. Bir alt profile uyan bir uygulama, kaynak kısıtlı donanım platformlarında çalışabilir ve/veya belirli uygulamaların ihtiyaçlarına hizmet edebilir.

En önemlileri arasında, çeşitli durumlarda uygulamanın davranışını tanımlayan kavramlar yer alır. Birçok doğru durum için davranış belirtilmemiştir, bu da bir mobil uygulamanın farklı uygulamaların davranışının çakışmasına dayanmaması gerektiği anlamına gelir. Yanlış durumlar için davranış tanımsız olabilir; Bir uygulama yalnızca bu tür davranışın tanımlanmış doğasına güvenmemeli, aynı zamanda tanımsız davranışa neden olan yanlış eylemler gerçekleştirmemelidir.

Bir başka yakından ilişkili terim olan "uygulamaya bağlı davranış", ayrıca bir uygulamanın davranışının belgelenmesi gerektiği anlamına gelir.

POSIX standardı, uzun yıllardır var olan, her yeni baskıda bir şeylerin ortaya çıktığı ve bir şeylerin kaybolduğu gelişen bir organizmadır. Kullanımdan kaldırılan, çeşitli uygulamalar tarafından hala desteklenen, ancak gelecekte ortadan kalkması muhtemel olan özelliklerdir. Yeni uygulamalar bunları kullanmamalıdır; standart, her biri için işlevsellik açısından yeterli modern bir ikame sağlar.

"Eski" terimine daha sınırlı bir anlam verilmiştir: yeni uygulamalarda elbette kaçınılması gereken eski isteğe bağlı özellikleri tanımlar.

Yazılımın (SW) hareketliliğinin (taşınabilirlik, taşınabilirlik) sağlanması, olağanüstü önem ve karmaşıklık gerektiren bir görevdir; zamanımızda, bu durumun kapsamlı gerekçelere ihtiyacı yoktur. Yazılım taşınabilirliğini artırmanın genel kabul görmüş yollarından biri, uygulama ortamını standart hale getirmektir: sağlanan programlama arabirimleri, yardımcı programlar vb. Düzeyinde sistem servisleri böyle bir ortam, POSIX (Taşınabilir İşletim Sistemi Arayüzü) standardı tarafından tanımlanır; isim, Özgür Yazılım Vakfı'nın kurucusu olan tanınmış uzman Richard Stallman tarafından önerildi. POSIX standardının mevcut en son sürümünü, "üçlü standart" olarak adlandırılabilecek 2003 sürümünü, yani IEEE Std 1003.1 standardını, Açık Grup Teknik Standardını ve (bizim için en önemli olan şeye bakın, uluslararası standart ISO/IEC 9945 (bakınız , , ) Bu sürümün geçmişi aşağıdaki gibidir: 1998 yılının başlarında, üç kuruluşun temsilcileri - Elektrik ve Elektronik Mühendisleri Enstitüsü Mobil Uygulama Standartları Komitesi, Açık Grup ve çalışma grubu Uluslararası Standardizasyon Örgütü'nün ortak teknik komitesi 1'in (JTC1/SC22/WG15) 22. alt komitesinin 15'i - sistem hizmetlerine arayüzler için küratörlük standartlarının birleştirilmesi ve geliştirilmesi konusunda istişarelere başladı: IEEE Std 1003.1, IEEE Std 1003.2, Open Grup Temel Spesifikasyonları, ISO/IEC 9945-1, ISO / IEC 9945-2 Aynı yılın Eylül ayında Austin, Teksas'ta, Belirlenen hedefe ulaşılması (bkz. http://www.opengroup.org/austin). İlk olarak Temmuz 1999'da hazırlanan revize standardın temel belgesi, IEEE ve ISO/IEC standartlarından hükümler içerdiği için Open Group'un Temel Spesifikasyonlarıydı. 2001 yılında, hazırlık çalışmalarının tamamlanmasının ardından standart aşağıdaki dört bölümü içeriyordu:

temel tanımlar (tüm parçalarda ortak olan terimler, kavramlar ve arayüzler);

sistem hizmetlerine uygulama programlama C-arayüzünün tanımı;

düzeyde sistem hizmetlerine arayüzün açıklaması komut dili ve yardımcı programlar;

standart hükümlerinin ayrıntılı açıklaması, alınan kararların gerekçesi.

Ayrıca, ISO, IEEE ve Open Group'ta az ya da çok hızla (2001-2002) yeni POSIX standardının resmi onayı geçti. Bu arada, 2003 baskısında dikkate alınan nispeten küçük düzeltmeler birikmiştir. Standardın gelişmesiyle birlikte "POSIX" teriminin yorumu da genişledi. İlk olarak, açıklanan IEEE Std 1003.1-1988'e atıfta bulundu. uygulama programlama Arayüzüİşletim sistemi sınıfı Unix. Arayüzün komut dili ve yardımcı program seviyelerinde standardizasyonu ile, standardı bir bütün olarak ifade etmek için "POSIX" kelimesini kullanmak, yukarıdaki 2. ve 3. bölümleri POSIX.1 ve POSIX.2 olarak belirtmek daha doğrudur. IEEE ve ISO/IEC belgelerinin numaralandırılmasına uygundur.

POSIX standardının temel fikirleri

POSIX standardı, uygulama programlarının çalışması için gereken bir dizi temel sistem hizmetini tanımlar. Bunlara C dili, komut dili ve yaygın olarak kullanılan yardımcı programlar için belirtilen bir arabirim aracılığıyla erişilir. Her arayüzün iki tarafı vardır: arayan ve aranan. POSIX standardı öncelikle arayan odaklıdır. Amacı başvuru yapmaktır. kaynak dil düzeyinde mobil. Bu, özellikle, C programlarını başka bir işletim platformuna taşırken yeniden derlemenin gerekli olduğu anlamına gelir. Yürütülebilir programların ve/veya nesne dosyalarının taşınabilirliğinden bahsetmiyoruz. POSIX standardı hiçbir şekilde Unix ortamıyla sınırlı değildir. "Bağımsız kökenli" işletim sistemleri (OS) vardır (örneğin, gerçek zamanlı sistemler) gerekli hizmetleri sağlayan ve böylece POSIX uyumlu uygulamaların yürütülmesini destekleyen. POSIX standardını izlemenin, uygulamaları hemen hemen her tür işletim platformuna taşımayı kolaylaştırdığı iddia edilebilir. Geliştirme aşamasına harcanan ekstra hareketlilik çabası kesinlikle karşılığını verecektir. POSIX, sistem hizmetlerine bir arabirim tanımlayarak, uygulamayı kapsam dışında bırakır. Özellikle, farklı değiller sistem çağrıları ve kütüphane fonksiyonları. Standardizasyona tabi değil yönetim, donanım sınırlamaları ve yalnızca gerekli özellikler süper kullanıcı, POSIX standardının işletim sistemlerine değil uygulamalara odaklandığını bir kez daha vurgular. POSIX, sistem mimarisi ve işlemci bitliği açısından nötrdür. Bu, uygulama hareketliliğinin çok önemli bir yönüdür. C dilinin uluslararası standardına yönelim, yalnızca işlevlerin tanımlanma stilini değil, aynı zamanda bir dereceye kadar her iki standardın senkronizasyonu açısından POSIX özelliklerinin gelişim yönünü de belirledi. Bilindiği gibi, C dili spesifikasyonlarının 1999 baskısı (bkz. ), POSIX işlevlerine karşılık gelen bir eklemeye neden olan karmaşık veri türünü meşrulaştırdı. POSIX standardı, zorunlu çekirdeğin mümkün olduğunca kompakt olmasıyla zorunlu ve isteğe bağlı işlevler arasında ayrım yapar. Elbette, hem "klasik" Unix ortamında hem de diğer işletim platformlarında, ağ ve dağıtılmış konfigürasyonlarda standartlaştırılmış işlevleri uygulama yollarına özel önem verilir. POSIX standardının yeni sürümünün geliştiricileri, tarih öncesi ve Unix sistemlerinin tarih öncesi ve en önemlisi, standardın önceki sürümlerini karşılayan uygulamalar konusunda çok dikkatliydi. Mevcut arayüzleri korumaya çalıştı; geliştirme sürecinde, ilke gözlemlendi geriye dönük uyumluluk; eski arayüzlerle çakışmaması için yeni arayüzler eklendi. Oldukça anlaşılabilir nedenlerden dolayı uygulamalarda değişiklik yapmaktan tamamen kaçınmak mümkün değildi: farklı ilk özellikler arasındaki çelişkileri ortadan kaldırmak ve ayrıca C dilinin "geleneksel" varyantını desteklemekten vazgeçip uluslararası standardına geçmek gerekiyordu.

POSIX standardının temel kavramları

2003 POSIX standardı, aşağıdaki sistem bileşeni kategorilerini ayrıntılandıran çok kapsamlı, çok yönlü bir belgedir:

Geliştirme araçları;

ağ tesisleri;

gerçek zamanlı tesisler;

kontrol akışları;

matematiksel arayüzler;

paket hizmetler;

başlık dosyaları;

eski arayüzler

Uygulamanın çalışması için işletim sisteminin sağlaması gereken (en üst düzeyde, tam olmaktan uzak) repertuar budur. En önemli kavram POSIX uyumluluğu. Her arayüzün iki tarafı olduğunu belirtmiştik: arama ve arama. POSIX uyumluluğunun ayrıca iki yönü vardır: uygulama (işletim sistemi) uyumluluğu ve uygulama uyumluluğu. POSIX standardına uygun bir uygulama (işletim sistemi), standartta belirtilen davranışı sağlarken gerekli tüm yardımcı programları, işlevleri, başlık dosyalarını desteklemelidir. _POSIX_VERSION sabiti 200112L değerine sahiptir. İşletim sistemi, standartta isteğe bağlı olarak işaretlenen özelliklerin yanı sıra standart dışı özellikler de içerebilir. Bir uzantının desteklendiği iddia ediliyorsa, bu, gerekli tüm parçalar için tutarlı bir şekilde ve standartta açıklandığı gibi yapılmalıdır. Başlık dosyasında desteklenen isteğe bağlı özelliklere karşılık gelen sabitleri tanımlamanız gerekir (örneğin, _POSIX2_C_DEV sabiti C geliştirme araçlarını sağlar). Uygulama, bu sabitleri derleme zamanında analiz ederek, kullanılan işletim sisteminin yeteneklerini anlayacak ve bunlara göre ayarlayacaktır. Benzer çalışma zamanı eylemleri, sysconf() işlevi ve/veya getconf yardımcı programı kullanılarak gerçekleştirilebilir. İşletim sisteminin ve uygulamaların boyutunu en aza indirmek için POSIX standardı, isteğe bağlı özelliklerin (toplamda kırk) çok ince bir ayrıntı düzeyi sağlar. Öte yandan, birbiriyle ilişkili isteğe bağlı özellikler, birçok durumda çok sayıda seçeneği analiz etme ihtiyacını ortadan kaldıran gruplar halinde birleştirilmiştir. Bu gruplar:

şifreleme;

gerçek zamanlı araçlar;

gelişmiş gerçek zamanlı araçlar;

gerçek zamanlı akışlar;

gelişmiş gerçek zamanlı akışlar;

izleme ;

CANLI YAYINLAR;

eski yetenekler.

Örneğin, "gerçek zamanlı araçlar" (_XOPEN_REALTIME) grubu, öncelik tabanlı zamanlama, eşzamansız G/Ç, semaforlar, zamanlayıcılar vb. dahil olmak üzere on dört tür yetenek içerir. Bu dersin metninin hazırlandığı Linux işletim sistemi sürümü, bazı yapılandırma sabitleri için aşağıdaki değerleri üretti (bkz. liste 1.1).

$ getconf _POSIX_VERSION 199506 $ getconf POSIX2_C_DEV 1 $ getconf _XOPEN_REALTIME 1 $ getconf _POSIX_TRACE tanımsız Liste 1.1. Getconf yardımcı programının Linux işletim sistemi sürümlerinden birine uygulanmasının sonucu.

Bu, POSIX standardının eski bir sürümünün desteklendiği, geliştirme araçlarının ve gerçek zamanlı yeteneklerin diğerleri arasında mevcut olduğu anlamına gelir; izciler yok. İşletim sistemi belgeleri, POSIX standardına uygunluk sorunlarını yansıtmalı, desteklenen ek ve standart dışı özellikleri açıklamalıdır. Uygulamalar için, POSIX uyumluluğu kavramı daha nüanslıdır. Sağlanan sıkı uyum, temel ayırt edici özelliği, standart çerçevesinde kullanılan özellik aralığının sınırlandırılmasıdır. Uzantıların kullanımına uygunluk da dikkate alınır; bu durumda, uygulama belgeleri gerekli standart dışı özelliklerin bir tanımını içermelidir. Kullanılan POSIX özellik uzantılarının uluslararası ve/veya ulusal standartlarla açıklanması arzu edilir. (Uygulama için katı POSIX uyumluluğu kavramının, yalnızca yönetim araçları olmadan işletim sistemi olmaması ve bu standart tarafından tanımlanmamaları nedeniyle anlamsız olduğunu unutmayın.) Profil, isteğe bağlı özellikleri tanımlayan bir seçenekler kümesidir. . Bir profile uygunluk, POSIX standardına uygunluk ve belirtilen yetenekler için destek anlamına gelir. Düzgün seçilmiş profiller, temsili kullanıcı ve/veya uygulama sınıflarının ihtiyaçlarını karşılar. Standart yeteneklerin alt kümelerini tanımlayan "alt profillerin" varlığına izin verilir. Bir alt profile uyan bir uygulama, kaynak kısıtlı donanım platformlarında çalışabilir ve/veya belirli uygulamaların ihtiyaçlarına hizmet edebilir. En önemlileri arasında, çeşitli durumlarda uygulamanın davranışını tanımlayan kavramlar yer alır. Birçok doğru durum için davranış belirtilmemiştir, bu da bir mobil uygulamanın farklı uygulamaların davranışının çakışmasına dayanmaması gerektiği anlamına gelir. Yanlış durumlar için davranış tanımsız olabilir; Uygulama, yalnızca bu davranışın belirli doğasına dayanmamalı, aynı zamanda hatalı eylemler gerçekleştirmemelidir. tanımsız davranış. Bir başka yakından ilişkili terim, uygulamaya bağlı davranış", ayrıca uygulamanın davranışının belgelenmesi gerektiği anlamına gelir. POSIX standardı, her yeni revizyonda bir şeyler eklenen ve kaybolan uzun süredir gelişen, gelişen bir organizmadır. Kullanımdan kaldırılan, çeşitli uygulamalar tarafından desteklenen özelliklerdir, ancak bunlar yeni uygulamalar bunları kullanmamalıdır; standart, her biri için yeterli işlevsel modern bir ikame sağlar. "Eski" terimine daha sınırlı bir anlam verilir: eski isteğe bağlı özellikleri tanımlar. Yeni uygulamalarda elbette kaçınılmalıdır.

POSIX standardına uygun işletim sistemlerinin temel kavramları

POSIX standardına uygun işletim sistemlerinin aşağıdaki temel kavramlarını ele alacağız:

kullanıcı ;

dosya ;

işlem ;

terminal ;

ev sahibi;

ağ düğümü;

zaman ;

dilsel ve kültürel çevre.

Bunlar birincil kavramlardır. Kesin olarak tanımlanamazlar, ancak diğer kavram ve ilişkilerin yardımıyla açıklanabilirler. Seçilen kavramların her biri için, içlerinde bulunan nitelikler ve bunlara uygulanabilir işlemler tanımlanacaktır. POSIX standardının metni, özniteliklere ve işlemlere yapılan referanslarla birlikte, temel kavramların aşağıdaki açıklamalarını içerir.

Kullanıcının bir adı ve sayısal bir kimliği vardır.

Dosya, okunabilen ve/veya yazılabilen ve izinler ve tür gibi niteliklere sahip bir nesnedir. İkincisi, normal dosya, karakter ve blok özel dosyaları, boru, sembolik bağlantı, soket ve dizin içerir. Bir uygulama, diğer dosya türlerini destekleyebilir.

İşlem, içinde çalışan denetim iş parçacıklarının yanı sıra bu iş parçacıklarının gerektirdiği sistem kaynaklarıyla birlikte bir adres alanıdır.

Bir uçbirim (veya uçbirim aygıtı), ortak bir uçbirim arabiriminin belirtimlerine uyan bir karakter özel dosyasıdır.

Ağ, birbirine bağlı ana bilgisayarlardan oluşan bir koleksiyondur.

Dil ve kültürel ortam - dil ve kültürel sözleşmelere bağlı olarak kullanıcı ortamının bir parçası.

Çok sayıda varlıkla çalışmak için her zaman hiyerarşileri gruplandırma ve oluşturma mekanizmaları sağlanır. Dosyalar, kullanıcı grupları ve işlemler, alt ağlar vb. hiyerarşisi vardır. POSIX uyumlu sistemlerin varlıkları ile çalışan programlar yazmak için bir komut yorumlayıcısı (kabuk dili) ve / veya derlenmiş C dili kullanılır.İlk durumda, uygulama yardımcı programları (yardımcı programları), ikinci - işlevlerde kullanabilir . Çoğu yardımcı program aslında belirli bir işlevi çağırmak için tasarlandığından, işletim sistemlerinin işlevsel arabirimi doğal olarak birincil olarak kabul edilir. Bu nedenle, aşağıda temel olarak fonksiyonların seviyesini ele alacağız. İşletim sistemi nesnelerine uygulanabilen ana işlemler okuma, yazma ve yürütmedir. Erişim hakları mekanizması, bu tür işlemlerin uygulanmasına seçici olarak izin vermenize ve yasaklamanıza izin verir. Daha önce standart, erişim kontrolüne tabi olmayan bir süper kullanıcı konseptini içeriyordu. POSIX-2001'de daha esnek bir ifade seçilmiştir - "sahip olmak uygun ayrıcalıklar", bölme süper kullanıcı yetenekleriyle işletim sisteminin uygulanmasındaki ilerlemeyi yansıtır. POSIX uyumlu işletim sistemleri, yardımcı olarak adlandırılabilecek nesneleri tanımlar; ana varlıklar arasındaki etkileşimi düzenlemeye yardımcı olurlar. Özellikle geniş bir araç yelpazesi arası iletişim. İşlemler, semboller ve özellikleri, mesaj biçimleri, tarih ve saat, sayısal ve parasal değerler gibi kategorilerden oluşan, bir kısmı dilsel ve kültürel ortam (Yerel) olan belirli bir ortamda yürütülür. Tipik olarak, bir işlemin kendisiyle ilişkilendirilmiş en az üç dosyası vardır - standart giriş, standart çıktı, standart protokol. Tipik olarak, terminalin klavyesine standart giriş atanır ve ekrana standart çıkış ve standart protokol atanır. Komutlar ve (bazen) bunlar için kaynak veriler standart girdiden okunur. Komutların sonuçları standart çıktıya gönderilir. Teşhis mesajları standart protokole yerleştirilir. İşletim sistemleri, gerçek zamanlı destek gereksinimi gibi kalite gereksinimlerine sahip olabilir: belirli bir süre için gerekli hizmeti sağlama yeteneği.

POSIX uyumlu uygulamalar için derleme ortamı

Kural olarak (her zaman gerçekleşmese de), uygulama geliştirme çapraz modda, yani bir geliştirme platformunda gerçekleştirilir (eşdeğer terim alet platformu) çalışma zamanı platformuyla aynı değildir (aynı zamanda hedef platform). Araç platformunda oluşturuldu uygulama derleme ortamı, böylece derleme sonucu hedef platformda daha sonra yürütülmek üzere taşınabilir. Derleme ortamının en önemli kısmı, aşağıdakileri içeren başlık (veya içerme) dosyalarıdır. fonksiyon prototipleri, tanımlar sembolik sabitler, makrolar , veri türleri, yapılar vb. POSIX standardında tanımlanan her işlev, onu kullanan uygulama tarafından hangi başlık dosyalarının dahil edilmesi gerektiğini tanımlar (genellikle bir dosya gerekir). Başlık dosyasında tanımlanan sembolik sabitler aracılığıyla yukarıda belirtilmişti. , işletim sistemi, uygulamaya desteklenen özellikler hakkında bilgi sağlar. POSIX standardı, adı verilen simetrik bir mekanizma sağlar. yetenek kontrol makroları, uygulamaların belirli prototiplere ve isimlere erişme isteklerini duyurmalarını sağlar. Ana özellik kontrol makrosu _POSIX_C_SOURCE'dir. Kesinlikle POSIX uyumlu uygulamalar için gereksinimler arasında, herhangi bir başlık dosyası eklemeden önce _POSIX_C_SOURCE sembolik sabitini 200112L değeriyle tanımlama ihtiyacı vardır. Böylece, POSIX uyumlu bir uygulama, POSIX adlarına ihtiyacı olduğunu beyan eder. _XOPEN_SOURCE makrosu (600 değeriyle) benzer bir rol oynar. _POSIX_C_SOURCE makrosunu kullanma örneği dahil edilen dosyalar Linux işletim sistemi, Liste 1.2'de gösterilen snippet işlevi görebilir.

#if tanımlı(_REENTRANT) || (_POSIX_C_SOURCE - 0 >= 199506L) #define LIBXML_THREAD_ENABLED#endif 1.2 Listeleme. _POSIX_C_SOURCE yetenek denetimi makrosunun kullanımına bir örnek.

POSIX standardı, bir uygulama ile işletim sistemi arasında bir adlandırma kuralının olmaması gibi önemli ve zor sorunu (öncelikle C dilinin nesnel olmayan yapısından kaynaklanan) ele almak için bazı önlemler sağlar. posix_ , POSIX_ ve _POSIX_ önekleri standardın ihtiyaçları için ayrılmıştır. Yalnızca sistem (uygulama değil) adları bir alt çizgi ile başlayabilir, ardından başka bir alt çizgi veya büyük bir İngilizce harf gelebilir. Dahil etme dosyaları için, bunlarda kullanılan adların önekleri açıklanmıştır. Örneğin, içinde görünen dosya yönetimi işlemleri için , F_ , O_ , S_ önek olarak kullanılır. Dosyada açıklanan süreçler arası iletişim olanakları , önek IPC_'dir. Ne yazık ki, birçok başlık dosyası var ve tarihsel nedenlerden dolayı genel bir adlandırma disiplini yok. Bu nedenle, dosyadaki terminallerin özelliklerini değiştirmek için birçok farklı isim tanımlanmıştır: EXTB , VDSUSP , DEFECHO , FLUSHO , vb. Ayrıca bir uygulamanın dış bağlantılarını düzenlemeye katılabilecek _Exit , abort , abs , acos vb. gibi dört yüz on yedi ad vardır. Sonuç olarak, bir uygulama programcısı yanlışlıkla bir sistem makrosunu, harici değişkeni veya işlevi "kesebilir", bu nedenle derleme ortamının tüm tanılama araçlarını kullanmanız ve bunlar tarafından verilen mesajları dikkatlice incelemeniz önerilir.

POSIX Uyumlu Uygulamaların Taşınabilirliği

POSIX uyumlu uygulamaların taşınabilirliği, iki ana faktör nedeniyle temelde elde edilebilir. Birincisi, bu, çok sayıda standartlaştırılmış sistem hizmetinin varlığı ve ikincisi, hedef platformun özelliklerini dinamik olarak belirleme ve uygulamayı bunlara göre ayarlama yeteneğidir. (Doğal olarak, standart çerçevesinde taşınabilirliği kastediyoruz.) POSIX standardına uygun uygulamalar, konfigürasyonu hedef platformun özelliklerine dinamik olarak uyarlama yeteneği ile tek ve çok işlemli olabilir. Üretme araçları ve süreç sonlandırma, programlarını değiştir, yoklama ve/veya çeşitli özellikleri değiştirme. İşlemler belirli zamanlarda duraklatılabilir ve etkinleştirilebilir. Sinyal mekanizması, olayları bildirmenize ve süreçleri harici olarak sonlandırmanıza olanak tanır. Bunları gruplandırmak için araçlar var. iş yönetimi. Uygulamalar, zamanlamayı yönetmek için kontrollerle sağlanır ve süreç öncelikleri. Çok çeşitli süreçler arası iletişim araçları ( mesaj kuyrukları, paylaşılan hafıza, semaforlar ) ve hafıza yönetimi. Son olarak, bir süreç içinde birden çok kontrol dizisi düzenlenebilir. Gerçek zamanlı destek araçları (bunlar arasında işlemci tahsisinin disiplin yönetimi, gerçek zamanlı sinyaller, RAM'de sayfa tutma, yüksek çözünürlüklü zamanlayıcılar vb.) sayesinde gerekli yürütme determinizmi elde edilir. Dosya işlevleri, bu tür verileri yetkisiz erişime karşı koruyarak, uzun vadeli verileri okumak ve yazmak için uygulamaların ihtiyaçlarını karşılar. mekanizma dosya parçası kilitleri işlemlerin atomitesini sağlamanıza olanak tanır. Asenkron G/Ç değişim işlemlerini birleştirmeyi mümkün kılar, böylece uygulamaları optimize eder. Birçok yardımcı programın yardımıyla karmaşık veri işleme nispeten kolay bir şekilde organize edilebilir. POSIX standardı, erişim konularını detaylandırır. harici cihazlar seri hatlar üzerinden, özellikle terminallere bağlanır. Manyetik bant gibi yaygın medya araçları için belki daha fazla ayrıntıya ihtiyaç vardır. Standartlaştırılmış kabuk komut dili, küçük mobil prosedürler yazmak ve bunları etkileşimli olarak hızlı bir şekilde hata ayıklamak için yeterli bir araçtır. Ara sonuçların filtrelenmesiyle komutları zincirler halinde birleştirmenize izin veren boru hattı mekanizmasını vurgulayalım. Yardımcı programlar, kabuk prosedürleri için zengin bir çalışma zamanı ortamı sağlar. Arka plan modu nedeniyle, birkaç programın aynı anda yürütülmesini düzenleyebilir ve çoklu pencere yetenekleri olmayan normal bir terminal aracılığıyla onlarla etkileşime girebilirsiniz (ancak, pencereler kesinlikle karışmaz). POSIX standartlaştırıyor komut satırı arayüzü. Prensip olarak yeterli, orta derecede uygun ve daha da önemlisi hareketlilik açısından minimum sorun yaratıyor. Muhtemelen, standardın gelecekteki sürümlerinde grafik arayüz düzenlenecektir, ancak elbette bu, mobil uygulama geliştiricileri için ek zorluklarla doludur. Dil ve kültürel ortam, hareketlilik açısından POSIX standardının en önemli kavramlarından biridir. Uygulamalar ihtiyaç duydukları ortamı belirleyebilir ve kullanıcıların ihtiyaçlarına göre uyarlanabilir. Çok kullanıcılı sistemler, çok sayıda insanın etkileşimini gerektirir. POSIX, bu sorunu doğrudan ve posta yoluyla bilgi alışverişi araçlarını düzenleyerek çözmektedir. POSIX standardı, (öncelikle C dili için) temel geliştirme desteği sağlar; bu, elbette, gerçekten büyük yazılım projeleriyle çalışma söz konusu olduğunda, özel, gelişmiş sistemlere olan ihtiyacı azaltmaz. Uygulamalar, hedef sistemin hem "büyük blok" özelliklerini (örneğin, desteklenen isteğe bağlı özellikler yelpazesi) hem de daha ince özellikleri (mevcut boş disk alanı gibi) bulmak için standart hale getirilmiş araçlarla sağlanır. Uygulama hareketliliği sorunu son derece karmaşıktır ve POSIX-2001 standardının bunu tamamen çözdüğünü iddia etmek abartı olur. İlk olarak, grafikler, çoklu pencere arayüzü ve diğerleri gibi önemli konular kapsamı dışında kalmaktadır. İkincisi, düzenlenmiş alanlarda "beyaz noktalar" var belirtilmemiş davranış uygulamalar. Ancak yinelemek gerekirse, POSIX standardına bağlılık, modern uygulama geliştirme disiplininin temel bir unsurudur.