Thursday, 29 November 2007

LINUX Çekirdeğini Anlamak – Süreçler 1 (Teknik İngilizce Çeviri Örneği)

LINUX Çekirdeğini Anlamak – Süreçler 1
Ali Rıza SARAL(1)

(1) Daniel P. Bovet, Marco Cesati, Understanding the Linux Kernel ‘den faydalanarak derlenmiştir.
(2) Bu yazı biraz da okuyucunun teknik İngilizce’sini geliştirmek amacı ile yazılmıştır.
(3) Bir diğer amaç ta teknik metinlerin Türkçe’ye tercüme edilişi hakkında tartışmağa imkan sağlamaktır.

Bölüm 3. LINUX’ta Süreçler
Chapter 3. Processes

Süreç kavramı her bir çoğul-programlayıcı (multi-programming) işletim sistemi için temel bir kavramdır. The concept of a process is fundamental to any multiprogramming operating system.

Bir süreç genellikle bir programın çalıştırılmakta olan bir örneğidir (instance);
A process is usually defined as an instance of a program in execution;

böylece, eğer 16 kullanıcı aynı anda vi programını çalıştırıyorsa, 16 tane ayrı süreç vardır
(aynı çalıştırılabilir kodu paylaşabildiklerine karşın).
thus, if 16 users are running vi at once, there are 16 separate processes (although they can share the same executable code).

Süreçlere Linux kaynak kodunda “görev” (task) adı verilir. Processes are often called "tasks" in Linux source code.

3.1 Süreç Tanımlayıcı (Process Descriptor)
Süreçleri yönetmek için, çekirdek, her sürecin ne yaptığına ilişkin net bir resme sahip olmalıdır. In order to manage processes, the kernel must have a clear picture of what each process is doing.

Örneğin, süreç önceliğini, CPU üzerinde çalışır durumda ya da bir olay nedeni ile tıkanmış olduğunu, hangi adres alanının ona atanmış olduğunu, hangi dosyalara erişişine izin verildiğini, ve benzerşeyleri bilmek zorundadır. It must know, for instance, the process's priority, whether it is running on the CPU or blocked on some event, what address space has been assigned to it, which files it is allowed to address, and so on.

Bu süreç tanımlayıcı’nın, yani tek bir sürece ilişkin bütün bilgileri içeren görev_yapısı (task_struct) tipinde bir yapının rolüdür. This is the role of the process descriptor , that is, of a task_struct type structure whose fields contain all the information related to a single process.

Şekil 3-1. Linux süreç tanımlayıcısı


3.1.1 Süreç Hali (Process State)
İsminden anlaşıldığı gibi, süreç tanımlayıcının hal (state) alanı süreç içinde o anda ne olduğunu tarif eder. As its name implies, the state field of the process descriptor describes what is currently happening to the process.

Her biri süreç durumunu tarif eden bir dizi bayraktan oluşur.
It consists of an array of flags, each of which describes a possible process state.

Güncel Linux sürümünde bu haller karşılıklı olarak birbirlerini hariç tutar, ve böylece kümenin yalnız bir bayrağı kaldırılımış diğerleri indirilmiş olur.
In the current Linux version these states are mutually exclusive, and hence exactly one flag of state is set; the remaining flags are cleared.

Aşağıdakiler mümkün süreç halleridir: The following are the possible process states:

GÖREV_ÇALIŞIYOR (TASK_RUNNING) Süreç ya CPU üstünde çalışıyor ya da çalıştırılmak için bekliyor. TASK_RUNNING The process is either executing on the CPU or waiting to be executed.

GÖREV_KESİNTİYE_UĞRAYABİLİR (TASK_INTERRUPTIBLE) Bir koşul gerçekleninceye kadar süreç askıda (uyuyor). TASK_INTERRUPTIBLE The process is suspended (sleeping) until some condition becomes true.

Bir donanım kesintisini başlatmak, sürecin beklediği bir sistem kaynağını serbest bırakmak, veya bir işaret teslim etmek bir süreci uyandıran koşullara örnektir, yani sürecin halini geriye
GÖREV_ÇALIŞIYOR (TASK_RUNNING) ’a getirirler. Raising a hardware interrupt, releasing a system resource the process is waiting for, or delivering a signal are examples of conditions that might wake up the process, that is, put its state back to TASK_RUNNING .

GÖREV_KESİNTİYE_UĞRATILAMAZ (TASK_UNINTERRUPTIBLE) bir önceki hal gibidir, yalnız uyuyan sürece bir işaret teslim edilişi hali değiştirmez. TASK_UNINTERRUPTIBLE Like the previous state, except that delivering a signal to the sleeping process leaves its state unchanged.

Bu süreç nadir olark kullanılır. Yine de, bir sürecin öngörülmüş bir olay oluncaya kadar kesintiye uğramadan beklemesi gerektiği belirli özel koşullar altında değerlidir.
This process state is seldom used. It is valuable, however, under certain specific conditions in which a process must wait until a given event occurs without being interrupted.

Örneğin, bir süreç bir cihaz dosyasını açtığında ve denk düşen cihaz sürücüsü denk düşen donanım cihazını yoklamağa başladığında bu hal kullanılabilir. For instance, this state may be used when a process opens a device file and the corresponding device driver starts probing for a corresponding hardware device.

Cihaz sürücüsü yoklayış tamamlanıncaya kadar kesintiye uğramamak zorundadır, ya da donanım cihazı belirsiz bir halde kalabilir.
The device driver must not be interrupted until the probing is complete, or the hardware device could be left in an unpredictable state.

GÖREV_DURDU (TASK_STOPPED) Süreç çalıştırılışı durduruldu: süreç bu duruma bir SIGSTOP, SIGTSTP, SIGTTIN, veya SIGTTOU işareti aldıktan sonra girer. TASK_STOPPED Process execution has been stopped: the process enters this state after receiving a SIGSTOP, SIGTSTP, SIGTTIN, or SIGTTOU signal.

Bir süreç bir diğeri tarafından izlendiğinde (bir hata bulucu bir test programını denemek için bir ptrace( ) sistem çağrısı çalıştırdığında ki gibi), herhangi bir işaret süreci GÖREV_DURDU (TASK_STOPPED) haline koyar. When a process is being monitored by another (such as when a debugger executes a ptrace( ) system call to monitor a test program), any signal may put the process in the TASK_STOPPED state.

GÖREV_ZOMBİ (TASK_ZOMBIE) Süreç çalıştırışı bitirildi, fakat anne süreç ölü süreç hakkında bilgi geriye vermek için henüz wait( )- benzeri sistem çağrısı (wait( ), wait3( ), wait4( ), veya waitpid( )) çıkarmadı. TASK_ZOMBIE Process execution is terminated, but the parent process has not yet issued a wait( )- like system call (wait( ), wait3( ), wait4( ), or waitpid( )) to return information about the dead process.

wait( )- benzeri çağrı yapılmadan önce, çekirdek ölü süreç tanımlayıcının içerdiği veriyi çöpe atamaz, çünkü ebeveyn ona ihtiyaç duyabilir. Before the wait( )-like call is issued, the kernel cannot discard the data contained in the dead process descriptor because the parent could need it.


3.1.2 Süreci Belirleyiş (Identifying a Process)
Lunix süreçleri kendilerine ait çekirdek veri yapılarınının önemli bir kısmını paylaşabildikleri halde—hafif-sıklet süreçler(lightweight processes)—her süreç kendine ait süreç tanımlayıcısına sahiptir. Although Linux processes can share a large portion of their kernel data structures—an efficiency measure known as lightweight processes—each process has its own process descriptor.

Bağımsız olarak çalıştırım programına alınabilen her çalıştırış bağlamı kendine ait süreç tanımlayıcısı sahibi olmalıdır. Each execution context that can be independently scheduled must have its own process descriptor.

Hafif-sıklet süreçler bir kullanıcı-seviyesinde kütüphane tarafından ele alınıp farklı bir çalıştırış akışı olan, kullanıcı-üslubu bağlar(user-mode threads)’la karıştırılmamalıdır.
Lightweight processes should not be confused with user-mode threads, which are different execution flows handled by a user-level library.

Süreç ile süreç tanımlayıcı arasında çok katı bire-bir denk düşüş 32-bit süreç tanımlayıcı adresini [1] süreci belirlemek için kullanışlı bir araç yapar. The very strict one-to-one correspondence between the process and process descriptor makes the 32-bit process descriptor address[1] a convenient tool to identify processes.

Bu adreslere süreç tanımlayıcı adresleri (process descriptor pointers) olarak değinilir. Çekirdeğin yarattığı süreçlere yaptığı değinişlerin çoğu süreç tanımlayıcı işaret-vericileri(pointer) aracılığı iledir. These addresses are referred to as process descriptor pointers. Most of the references to processes that the kernel makes are through process descriptor pointers.

[1] Teknik açıdan 32 bit mantıksal adresin(logical) yalnız öteleyiş(offset) bileşenidir.
Technically speaking, these 32 bits are only the offset component of a logical address.

Yine de, Linux tek bir çekirdek veri kesimi(segment) kullandığı için, öteleyişin tam bir mantıksal adrese(whole logical address) eşdeğer kabul edebiliriz. However, since Linux makes use of a single kernel data segment, we can consider the offset to be equivalent to a whole logical address.

Dahası, kodun ve veri kesimleri(data segments)’nin taban adres(base address)’i 0 yapıldığı için, öteleyişi(offset) doğrusal bir addres gibi kullanabiliriz. Furthermore, since the base addresses of the code and data segmentsare set to 0, we can treat the offset as a linear address.

Öte yandan, herhangi bir UNIX-benzeri sistem, kullanıcılarının süreçleri Süreç Kimlik Nosu(Process ID (or PID)) adı verilen bir sayı aracılığıyla belirleyişine müsaade eder.
Any Unix-like operating system, on the other hand, allows users to identify processes by means of a number called the Process ID (or PID).

Süreç Kimlik NO’su (PID) süreç tanımlayıcının pid alanında tutulan 32-bit işaretsiz bir sayıdır. The PID is a 32-bit unsigned integer stored in the pid field of the process descriptor.

PID’ler sıra ile sayılandırılmıştır:yeni yaratılan bir sürecin PID’i normalde bir öncekinin PID’inin bir ile arttırılmışıdır. PIDs are numbered sequentially: the PID of a newly created process is normally the PID of the previously created process incremented by one.

Yine de, 16-bit donanım platformları için üretilmiş geleneksel UIX sistemleri ile uyumluluk için, LINUX üzerinde izin verilen en büyük PID sayısı 32767’dir. However, for compatibility with traditional Unix systems developed for 16-bit hardware platforms, the maximum PID number allowed on Linux is 32767.

Çekirdek sistemdeki 32768’inci süreci yarattığı zaman, aşağıdaki kullanılmamış PID’ları yeniden kullanmaya başlamalıdır. When the kernel creates the 32768th process in the system, it must start recycling the lower unused PIDs.

Etkinlik önemlidir çünkü öldür() ( kill( )) gibi bir çok sistem çağrısı etkilenen süreci belirtmek için PID’ı kullanır. Efficiency is important because many system calls like kill( ) use the PID to denote the affected process.

3.1.2.1 Görev dizisi (The task array)
Süreçler sistem içinde yaşam süreleri birkaç milisaniyeden aylara kadar uzanan devinimsel (dynamic) varlıklardır (entities). Processes are dynamic entities whose lifetimes in the system range from a few milliseconds to months. Thus, the kernel must be able to handle many processes at the same time.

Linux SY_GÖREV (NR_TASKS) kadar sürece muamele edebilir.
Linux is able to handle up to NR_TASKS processes.

Çekirdek kendi adress alanında görev (task) adı verilen SY_GÖREV (NR_TASKS) büyüklüğünde küresel sabit bi dizi (global static array) ayırır. Bu dizinin elemanları süreç tanımlayıcıya işaret edicilerdir (process descriptor pointers); boşluğa(null) işaret edici bir süreç tanımlayıcının o dizi elemanı ile ilişkilendirilmediğini belirtir. The kernel reserves a global static array of size NR_TASKS called task in its own address space. The elements in the array are process descriptor pointers; a null pointer indicates that a process descriptor hasn't been associated with the array entry.

3.1.2.2 Bir Süreç Tanımlayıcının Saklanışı (Storing a process descriptor)
görev (task) dizisi yalnız süreç tanımlayıcıların işaret edicilerini içine alır, çok yer kaplayan tanımlayıcıların kendilerini değil. The task array contains only pointers to process descriptors, not the sizable descriptors themselves.

Süreçler devinimsel varlıklar (dynamic entities) olduğu için, süreç tanımlayıcılar çekirdeğe kalıcı olarak atanan bellek alanına değil devinimsel belleğe depolanırlar. Since processes are dynamic entities, process descriptors are stored in dynamic memory rather than in the memory area permanently assigned to the kernel.

Linux her süreç için, 8KB bellek alanına, iki farklı veri yapısı saklar: süreç tanımlayıcı ve Çekirdek-üslubu (Kernel Mode) süreç yığını. Linux stores two different data structures for each process in a single 8 KB memory area: the process descriptor and the Kernel Mode process stack.


Şekil 3-2. Süreç tanımlayıcı ve süreç çekirdek yığınının saklanışı
Figure 3-2. Storing the process descriptor and the process kernel stack

esp kayıt-tutucusu(register) yığının en üst konum adresini tutan yığın eşaret-edicisidir.
The esp register is the CPU stack pointer, which is used to address the stack's top location.

Intel sistemlerinde, yığın sonda başlar ve bellek alanının başlangıcına doğru genişler.
On Intel systems, the stack starts at the end and grows toward the beginning of the memory area.

Kullanıcı-Üslubundan Çekirdek-Üslubuna geçişten hemen sonra, bir sürecin çekirdek yığını her zaman boştur, ve bu yüzden esp kayıt-tutucusu bellek alanından hemen sonra gelen byte’a işaret eder. Right after switching from User Mode to Kernel Mode, the kernel stack of a process is always empty, and therefore the esp register points to the byte immediately following the memory area….

3.1.2.3 Güncel Makrosu (The current macro)
Çekirdek-üslubu yığını ile süreç tanımlayıcı eşleştirişi etkinlik açısından anahtar bir fayda sağlar: çekirdek esp kayıt-tutucusunun değerinden CPU üzerinde çalışan sürecin süreç tanımlayıcısına işaret-ediciyi kolaylıkla elde edebilir.
The pairing between the process descriptor and the Kernel Mode stack just described offers a key benefit in terms of efficiency: the kernel can easily obtain the process descriptor pointer of the process currently running on the CPU from the value of the esp register.

Aslında, bellek alanı 8 KB(213 byte) uzunluğunda olduğundan, süreç tanımlayıcının taban adresini elde etmek için, çekirdeğin bütün yapması gereken, esp ‘nin en az önemli 13 bitini maskeleyerek çıkarmaktır. Bu şuanki (current) makrosu tarafından yapılır.
In fact, since the memory area is 8 KB (213 bytes) long, all the kernel has to do is mask out the 13 least significant bits of esp to obtain the base address of the process descriptor. This is done by the current macro…

Görev_yapısı-dizisi (task_struct_stack) arabölge (cache) içindeki süreç tanımlayıcılarının işaret edicilerini içinde bulundurur. The task_struct_stack array contains the pointers to the process descriptors in the cache.

İsmi süreç tanımlayıcı serbest bırakılışı ve istekte bulunuluşunun dizi üzerinde “it”(push) ve “çek”(pop) işlemleri ile yapılışından gelir:
Its name comes from the fact that process descriptor releases and requests are implemented respectively as "push" and "pop" operations on the array:

Görev_yapısını_serbest_birak (free_task_struct( )) Bu fonksiyon 8 KB’lık görev_birimi (task_union) bellek alanlarını serbest bırakır ve onları eğer boş değilse arabölge(cache)’ye yerleştirir.
free_task_struct( ) This function releases the 8 KB task_union memory areas and places them in the cache unless it is full.

Görev_yapısına_yer_ata (alloc_task_struct( )) Bu fonksiyon görev_birimi (task_union) bellek alanları için 8 KB yer atar. alloc_task_struct( ) This function allocates 8 KB task_union memory areas.

Bu fonksiyon eğer yarı-dolu ise ya da art arda gelen bir çift sayfa çerçevesi(page frame) yok ise arabölge(cache)’den bellek alanları alır.
The function takes memory areas from the cache if it is at least half-full or if there isn't a free pair of consecutive page frames available.

LINUX Çekirdeğini Anlamak – Süreçler 1


Şekil 3-1. Linux süreç tanımlayıcısı Şekil 3-2. Süreç tanımlayıcı ve süreç çekirdek yığınının saklanışı

LINUX Çekirdeğini Anlamak – Süreçler 1

Ali Rıza SARAL(1)


(1) Daniel P. Bovet, Marco Cesati, Understanding the Linux Kernel ‘den faydalanarak derlenmiştir.
(2) Bu yazı biraz da okuyucunun teknik İngilizce’sini geliştirmek amacı ile yazılmıştır.
(3) Bir diğer amaç ta teknik metinlerin Türkçe’ye tercüme edilişi hakkında tartışmağa imkan sağlamaktır. Bu amaçla cümle cümle tercümeyi içeren bir sürümünü de bulmak mümkündür.


Bölüm 3. LINUX’ta Süreçler (Processes)
Süreç kavramı her bir çoğul-programlayıcı (multi-programming) işletim sistemi için temel bir kavramdır. Bir süreç genellikle bir programın çalıştırılmakta olan bir örneğidir (instance);
böylece, eğer 16 kullanıcı aynı anda vi programını çalıştırıyorsa, 16 tane ayrı süreç vardır
(aynı çalıştırılabilir kodu paylaşabildiklerine karşın). Süreçlere Linux kaynak kodunda “görev” (task) adı verilir.

3.1 Süreç Tanımlayıcı (Process Descriptor)
Süreçleri yönetmek için, çekirdek, her sürecin ne yaptığına ilişkin net bir resme sahip olmalıdır. Örneğin, süreç önceliğini, CPU üzerinde çalışır durumda ya da bir olay nedeni ile tıkanmış olduğunu, hangi adres alanının ona atanmış olduğunu, hangi dosyalara erişişine izin verildiğini, ve benzerşeyleri bilmek zorundadır. Bu süreç tanımlayıcı’nın, yani tek bir sürece ilişkin bütün bilgileri içeren görev_yapısı (task_struct) tipinde bir yapının rolüdür.
.
Şekil 3-1. Linux süreç tanımlayıcısı


3.1.1 Süreç Hali (Process State)
İsminden anlaşıldığı gibi, süreç tanımlayıcının hal (state) alanı süreç içinde o anda ne olduğunu tarif eder. Her biri süreç durumunu tarif eden bir dizi bayraktan oluşur.
Güncel Linux sürümünde bu haller karşılıklı olarak birbirlerini hariç tutar, ve böylece kümenin yalnız bir bayrağı kaldırılımış diğerleri indirilmiş olur. Aşağıdakiler mümkün süreç halleridir:

GÖREV_ÇALIŞIYOR (TASK_RUNNING) Süreç ya CPU üstünde çalışıyor ya da çalıştırılmak için bekliyor.

GÖREV_KESİNTİYE_UĞRAYABİLİR (TASK_INTERRUPTIBLE) Bir koşul gerçekleninceye kadar süreç askıda (uyuyor). Bir donanım kesintisini başlatmak, sürecin beklediği bir sistem kaynağını serbest bırakmak, veya bir işaret teslim etmek bir süreci uyandıran koşullara örnektir, yani sürecin halini geriye GÖREV_ÇALIŞIYOR (TASK_RUNNING) ’a getirirler.

GÖREV_KESİNTİYE_UĞRATILAMAZ (TASK_UNINTERRUPTIBLE) bir önceki hal gibidir, yalnız uyuyan sürece bir işaret teslim edilişi hali değiştirmez. Bu süreç nadir olark kullanılır. Yine de, bir sürecin öngörülmüş bir olay oluncaya kadar kesintiye uğramadan beklemesi gerektiği belirli özel koşullar altında değerlidir. Örneğin, bir süreç bir cihaz dosyasını açtığında ve denk düşen cihaz sürücüsü denk düşen donanım cihazını yoklamağa başladığında bu hal kullanılabilir. Cihaz sürücüsü yoklayış tamamlanıncaya kadar kesintiye uğramamak zorundadır, ya da donanım cihazı belirsiz bir halde kalabilir.

GÖREV_DURDU (TASK_STOPPED) Süreç çalıştırılışı durduruldu: süreç bu duruma bir SIGSTOP, SIGTSTP, SIGTTIN, veya SIGTTOU işareti aldıktan sonra girer. Bir süreç bir diğeri tarafından izlendiğinde (bir hata bulucu bir test programını denemek için bir ptrace( ) sistem çağrısı çalıştırdığında ki gibi), herhangi bir işaret süreci GÖREV_DURDU (TASK_STOPPED) haline koyar.

GÖREV_ZOMBİ (TASK_ZOMBIE) Süreç çalıştırışı bitirildi, fakat anne süreç ölü süreç hakkında bilgi geriye vermek için henüz wait( )- benzeri sistem çağrısı (wait( ), wait3( ), wait4( ), veya waitpid( )) çıkarmadı. wait( )- benzeri çağrı yapılmadan önce, çekirdek ölü süreç tanımlayıcının içerdiği veriyi çöpe atamaz, çünkü ebeveyn ona ihtiyaç duyabilir.


3.1.2 Süreci Belirleyiş (Identifying a Process)
Lunix süreçleri kendilerine ait çekirdek veri yapılarınının önemli bir kısmını paylaşabildikleri halde—hafif-sıklet süreçler(lightweight processes)—her süreç kendine ait süreç tanımlayıcısına sahiptir. Bağımsız olarak çalıştırım programına alınabilen her çalıştırış bağlamı kendine ait süreç tanımlayıcısı sahibi olmalıdır. Hafif-sıklet süreçler bir kullanıcı-seviyesinde kütüphane tarafından ele alınıp farklı bir çalıştırış akışı olan, kullanıcı-üslubu bağlar(user-mode threads)’la karıştırılmamalıdır. Süreç ile süreç tanımlayıcı arasında çok katı bire-bir denk düşüş 32-bit süreç tanımlayıcı adresini [1] süreci belirlemek için kullanışlı bir araç yapar. Bu adreslere süreç tanımlayıcı adresleri (process descriptor pointers) olarak değinilir. Çekirdeğin yarattığı süreçlere yaptığı değinişlerin çoğu süreç tanımlayıcı işaret-vericileri(pointer) aracılığı iledir.

[1] Teknik açıdan 32 bit mantıksal adresin(logical) yalnız öteleyiş(offset) bileşenidir. Yine de, Linux tek bir çekirdek veri kesimi(segment) kullandığı için, öteleyişin tam bir mantıksal adrese(whole logical address) eşdeğer kabul edebiliriz. Dahası, kodun ve veri kesimleri(data segments)’nin taban adres(base address)’i 0 yapıldığı için, öteleyişi(offset) doğrusal bir addres gibi kullanabiliriz.

Öte yandan, herhangi bir UNIX-benzeri sistem, kullanıcılarının süreçleri Süreç Kimlik Nosu(Process ID (or PID)) adı verilen bir sayı aracılığıyla belirleyişine müsaade eder.
Süreç Kimlik NO’su (PID) süreç tanımlayıcının pid alanında tutulan 32-bit işaretsiz bir sayıdır. PID’ler sıra ile sayılandırılmıştır:yeni yaratılan bir sürecin PID’i normalde bir öncekinin PID’inin bir ile arttırılmışıdır. Yine de, 16-bit donanım platformları için üretilmiş geleneksel UIX sistemleri ile uyumluluk için, LINUX üzerinde izin verilen en büyük PID sayısı 32767’dir. Çekirdek sistemdeki 32768’inci süreci yarattığı zaman, aşağıdaki kullanılmamış PID’ları yeniden kullanmaya başlamalıdır. Etkinlik önemlidir çünkü öldür() ( kill( )) gibi bir çok sistem çağrısı etkilenen süreci belirtmek için PID’ı kullanır.

3.1.2.1 Görev dizisi (The task array)
Süreçler sistem içinde yaşam süreleri birkaç milisaniyeden aylara kadar uzanan devinimsel (dynamic) varlıklardır (entities). Linux SY_GÖREV (NR_TASKS) kadar sürece muamele edebilir. Çekirdek kendi adress alanında görev (task) adı verilen SY_GÖREV (NR_TASKS) büyüklüğünde küresel sabit bi dizi (global static array) ayırır. Bu dizinin elemanları süreç tanımlayıcıya işaret edicilerdir (process descriptor pointers); boşluğa(null) işaret edici bir süreç tanımlayıcının o dizi elemanı ile ilişkilendirilmediğini belirtir.

3.1.2.2 Bir Süreç Tanımlayıcının Saklanışı (Storing a process descriptor)
görev (task) dizisi yalnız süreç tanımlayıcıların işaret edicilerini içine alır, çok yer kaplayan tanımlayıcıların kendilerini değil. Süreçler devinimsel varlıklar (dynamic entities) olduğu için, süreç tanımlayıcılar çekirdeğe kalıcı olarak atanan bellek alanına değil devinimsel belleğe depolanırlar. Linux her süreç için, 8KB bellek alanına, iki farklı veri yapısı saklar: süreç tanımlayıcı ve Çekirdek-üslubu (Kernel Mode) süreç yığını.


Şekil 3-2. Süreç tanımlayıcı ve süreç çekirdek yığınının saklanışı
Figure 3-2. Storing the process descriptor and the process kernel stack

esp kayıt-tutucusu(register) yığının en üst konum adresini tutan yığın eşaret-edicisidir. Intel sistemlerinde, yığın sonda başlar ve bellek alanının başlangıcına doğru genişler. Kullanıcı-Üslubundan Çekirdek-Üslubuna geçişten hemen sonra, bir sürecin çekirdek yığını her zaman boştur, ve bu yüzden esp kayıt-tutucusu bellek alanından hemen sonra gelen byte’a işaret eder.

3.1.2.3 Güncel Makrosu (The current macro)
Çekirdek-üslubu yığını ile süreç tanımlayıcı eşleştirişi etkinlik açısından anahtar bir fayda sağlar: çekirdek esp kayıt-tutucusunun değerinden CPU üzerinde çalışan sürecin süreç tanımlayıcısına işaret-ediciyi kolaylıkla elde edebilir. Aslında, bellek alanı 8 KB(213 byte) uzunluğunda olduğundan, süreç tanımlayıcının taban adresini elde etmek için, çekirdeğin bütün yapması gereken, esp ‘nin en az önemli 13 bitini maskeleyerek çıkarmaktır. Bu şuanki (current) makrosu tarafından yapılır.

Görev_yapısı-dizisi (task_struct_stack) arabölge (cache) içindeki süreç tanımlayıcılarının işaret edicilerini içinde bulundurur. İsmi süreç tanımlayıcı serbest bırakılışı ve istekte bulunuluşunun dizi üzerinde “it”(push) ve “çek”(pop) işlemleri ile yapılışından gelir:

Görev_yapısını_serbest_birak (free_task_struct( )) Bu fonksiyon 8 KB’lık görev_birimi (task_union) bellek alanlarını serbest bırakır ve onları eğer boş değilse arabölge(cache)’ye yerleştirir.
Görev_yapısına_yer_ata (alloc_task_struct( )) Bu fonksiyon görev_birimi (task_union) bellek alanları için 8 KB yer atar. alloc_task_struct( ). Bu fonksiyon eğer yarı-dolu ise ya da art arda gelen bir çift sayfa çerçevesi(page frame) yok ise arabölge(cache)’den bellek alanları alır.

Wednesday, 21 November 2007

Munich TID views

Yapmış olduğum bir OD için kullandığım
TID durumları ve OD metni aşağıdadır.
Saygılar
Ali R+ SARAL

OD9308001 930307 SAL OD 93/08 XFL cjanges for EDDM, EDMO, EDSI cases -------
1. Subject : XFL changes
2. Case : Coordination procedures for flights to EDDM,
EDMO and EDSI have been changed. Arrivals to
these aerodromes will leave DKB at:
FL 280 approaching from FFM (UB1) or from
WUR (UB230), FL 270 approaching from ELL or
TGO (UR11).
The XFL logic should support a.m. rules whereby
the XFL is to be dynamic, i.e. if CFL or KFL is
lower than the XFL then the valid CFL or KFL
over DKB should be taken.
3. Requirement:Change the XFL logic for arrivals to EDDM, EDMO
and EDSI to:
- FL 270 when approaching DKB from ELL or TGO
and
- FL 280 when approaching DKB from all other
points.
These XFL-values should be overwritten by the
CFL or KFL valid for DKB when lower than the
XFL.
These changes will operationally be set in
force on 01.04.1993. The technical
implementation should be planned accordingly.
=============================================
POSITION: FE2 FRANKFURT
--------- --- ---------
T1 B737/M A1111 470
KJFK EDDM
1204 300 SPI 250 NE2
1210 NTM L
1220 FFM FE2 L
1229 KRH SE2 L
1233 TGO 270 TE2 L
1239 270 DKB ZE2 L
1246 WLD
FE2#TID: RECLEAR T1
=============================================
POSITION: FE2 FRANKFURT
--------- --- ---------
=============================================
POSITION: FE2 FRANKFURT
--------- --- ---------
T1 B737/M A1111 470
KJFK EDDM
1204 300 SPI 250 NE2
1210 NTM 240 L
1220 240 FFM FE2 L
1229 KRH SE2 L
1233 TGO TE2 L
1239 DKB ZE2 L
1246 WLD
FE2#TID: RECLEAR T1
=============================================
POSITION: FE2 FRANKFURT
--------- --- ---------
=============================================
POSITION: FE2 FRANKFURT
--------- --- ---------
T1 B737/M A1111 470
KJFK EDDM
1204 300 SPI 250 NE2
1210 NTM 240 L
1220 240 FFM 310 FE2 L
1229 310 KRH SE2 L
1233 TGO 270 TE2 L
1239 270 DKB ZE2 L
1246 WLD
FE2#TID: RECLEAR T1
=============================================
POSITION: FE2 FRANKFURT
--------- --- ---------
=============================================
POSITION: FE2 FRANKFURT
--------- --- ---------
T1 B737/M A1111 470
KJFK EDDM
1204 300 SPI 250 NE2
1210 NTM 240 L
1220 240 FFM 310 FE2 L
1229 310 KRH 250 SE2 L
1233 250 TGO TE2 L
1239 DKB ZE2 L
1246 WLD
FE2#TID: RECLEAR T1
=============================================
POSITION: FE2 FRANKFURT
--------- --- ---------
=============================================
POSITION: FE2 FRANKFURT
--------- --- ---------
T1 B737/M A1111 470
KJFK EDDM
1204 300 SPI 250 NE2
1210 NTM 240 L
1220 240 FFM 310 FE2 L
1229 310 KRH 250 SE2 L
1233 250 TGO 230 TE2 L
1239 230 DKB ZE2 L
1246 WLD
FE2#TID: RECLEAR T1
=============================================
POSITION: FE2 FRANKFURT
--------- --- ---------
=============================================
POSITION: FE2 FRANKFURT
--------- --- ---------
FE2#TID: FDM1 T1
=============================================
POSITION: FE2 FRANKFURT
--------- --- ---------
T1 B737/M A1111 470
KJFK EDDM
1204 300 SPI 250 NE2
1210 NTM 240 L
1220 240 FFM 310 FE2 L
1229 310 KRH 250 SE2 L
1233 250 TGO 230 TE2 L
1239 230 DKB ZE2 L
1246 WLD
=============================================
POSITION: ZE2 WUERZBURG
--------- --- ---------
TT2 B737/M A1111 470
LFPG EDMO
PEN 1345 240 DKB
### #### ### ###
1330 240 STR 250 SE2 L
1335 HERBI L
1339 TGO TE2 L
1345 DKB ZE2 L
1351 WLD
ZE2#TID: RECLEAR TT2
=============================================
POSITION: ZE2 WUERZBURG
--------- --- ---------
=============================================
POSITION: ZE2 WUERZBURG
--------- --- ---------
TT2 B737/M A1111 470
LFPG EDMO
PEN 1345 240 DKB
### #### ### ###
1330 240 STR 310 250 SE2 L
1335 HERBI L
1339 310 TGO 270 TE2 L
1345 270 DKB ZE2 L
1351 WLD
=============================================
POSITION: TC2 TANGO
--------- --- -----
TT1 B737/M A1111 470
EBBR EDMO
PEN 1356 240 DKB
### #### ### ###
1335 240 NTM 250 NE2 L
1342 RMS L
1348 KRH SE2 L
1354 ELL TE2 L
1356 DKB ZE2 L
1403 WLD
TC2#TID: RECLEAR TT1
=============================================
POSITION: TC2 TANGO
--------- --- -----
=============================================
POSITION: TC2 TANGO
--------- --- -----
TT1 B737/M A1111 470
EBBR EDMO
PEN 1356 270 DKB
### #### ### ###
1335 240 NTM 310 250 NE2 L
1342 RMS L
1348 310 KRH SE2 L
1354 ELL 270 TE2 L
1356 270 DKB ZE2 L
1403 WLD

TOUCH INPUT DEVICE - TID

Merhabalar,
Gunde 3500 ucakla bas eden MODERN bir sistem Touch Input Device kullanmak zorundadır.Fotograflarda Keyboard yalnızca flight data assistant'in önünde gozukmeli.
Saygilarimla ince dikkatlerinize.
Ali R+ SARAL


...
... A R+ S
...
105755007.1.1.4 TID
10575600 ---
10576000By use of the TID, a dynamic keyboard, the controller can enter messages
10576100and requests into the system. The keys are presented dynamically in a
10576200way that only syntactically correct input sequences may be typed in.
10576300.sp
10576400For the TID itself no separate error treatment is implemented, but the
10576500proper working of the both manual device multiplexers (MIX) used as
10576600data path between PC's and TID's is controlled. In case of error the
10576700MIX's are automatically reconfigured.
...
... A R+ S
...
004600014. General Use of the TID
00470001 4.1 Requirements for TID Use
00480001 4.2 General Layout
00490001 4.2.1
00500001 4.2.2 Sequence Control Touches
00510001 4.2.3 Display and Cancellation of Aircraft Callsign on the TID
00520001 4.3 Sequences Starting with Callsign
00530001 4.4 Sequences Starting with "SET"
00540001 4.5 Summary of Inputs
00550001 4.5.1 Inputs after Callsign
00560001 4.5.2 Inputs after SET
00570001 4.5.3 Input Availability

078700003.4 Touch Input Area (TIA)
07880000 ----------------------
07920000The TIA comprises two parts which are interactive as a TID input is carried out.
07950000It consists of:
07970000a) The readback area (RBA)
07980000b) The label block area (LBA)
08010000The LBA is the operator input device proper. It is used to display label blocks which indicate, during the different stages
08020000of an input sequence, the significance of the individual touches. The RBA is used during the composition of a TID sequence to
08030000display data corresponding to individual touch actions.
08050000In case of erroneous input during and/or after an input sequence the RBA may also show error/warning messages. See list on
08060000next page.
085900004. General Use of the TID
08600000 ----------------------
086200004.1 Requirements for TID use
08630000 ------------------------
08670000The Touch Input Device (TID) is used in conjunction with the EDD picture to give the controllers easy access to flight
08680000related data.
08700000This device is available at planning, executive coordinator and executive controller positions, who can insert orders to
08710000modify, insert or cancel data related to the selected flight.
08730000The rest picture is that picture presented on the EDD under the TID mask when no action is engaged. This picture contains
08740000labels of general use and a set of callsign labels.
08760000When touching a wire the controller is presented with a new picture with new labels; this can be repeated until the
08770000completion of the order which is then sent to the system when the 'EXEC' touch is pressed.
08790000The labels on the different label blocks are arranged in such a manner that the OPS requirements are met:
08820000a) The label blocks are presented such that they give guidance to the controller when composing the input.
08850000b) The set of input orders for the different positions are arranged so that they all make a mosaic picture which avoids a
08860000change in the presentation of the set of input orders as a result of an operational position management input. ex. planning
08870000controller combined with an executive coordinator and an executive.
08900000c) The touches necessary to make an input are minimized.
089500004.2 General Layout
08960000 --------------
08970000.SP
089800004.2.1
09010000The TID is a frame of 19 touches superimposed on the LBA of the EDD. The touches are organised horizontally in three rows of
090200006 touches and one vertical touch reserved for execution (EXEC) of an input order.
09030000Figure III.4.1 shows the three main TID blocks i.e.
09060000a) Rest-picture
09070000 ------------
09110000This is displayed when the TID is not in use. It displays callsigns of aircraft currently under control of this position plus
09120000those foreseen to be coming within a certain time parameter. Up to 15 callsigns may be displayed on this page. The NEXT touch
09130000may be used to display the next callsign page if more than 15 are available for use.
09140000An arrow is displayed in the LBA if callsigns
...
... A R+ S
...
09200000b) Callsign Options
09210000 ----------------
09250000After selection of a callsign from the 'REST' picture the callsign options are displayed.
09290000c) SET Options
09300000 -----------
09340000After selection of SET from the 'REST' picture, the SET options are
09350000displayed.
09380000Three different TID sets may be defined, one for each of the control position types i.e. Planner, Coordinator and Executive.
094300004.2.2 Sequence Control Touches
09440000 ------------------------
09470000Three sequence control touches are provided:
09490000a) EXEC
09500000 ----
09530000When touched at the end of an input sequence it instructs the system to execute the input order and then to redisplay the
09540000rest picture provided the input was accepted by the system.
09580000b) BTK Back Track
09590000 ---------------
...
... A R+ S
...
09690000c) RESET
09700000 -----
...
... A R+ S
...
097900004.2.3 Display and Cancellation of Aircraft Callsign on the TID
09800000 --------------------------------------------------------
09840000In the N-state and for the first ECO and EC within an M-state the parameters for the automatic display of TID callsigns are
09850000based upon Sector Boundary, or LPN if LPN is IN (i.e. LAD; POP-UP; LRS Change).
09860000In the case of an on-off change point the parameter for the second EC is
09870000in relation to the on-off change point.
09890000In the M-state callsigns are
...
... A R+ S
...
09920000For an aircraft for which an APL is input it is normal that an EC should be nominated during the KDS input of the APL. When
09930000the KDS order is entered the aircraft callsign will be displayed immediately to the nominated EC and his associated PLC/ECO.
09940000An APL callsign will only be displayed to a next and any subsequent sector EC and PLC/ECO upon 'handoff' of the previous EC.
09960000In M-forced callsigns
...
... A R+ S
...
09980000.nf
09990000Aircraft callsigns will be deleted from the TID either.
10010000a) upon 'Assume Control' of the next EC
10030000b) upon manual cancellation of the flight plan (CNL) or of the
10040000 LRS (CNLLRS)
10060000c) or
...
... A R+ S
...
10100000It should be noted that no automatic cancellation of a plan will be effected for an aircraft in the M-state or in M-forced
...
... A R+ S
...
.
10110000An APL will be cancelled automatically after 1 hour unless
...
... A R+ S
...
101800004.3 Sequences starting with callsign
10190000 --------------------------------
10220000- Assume control
10240000-------------
10250000To assume reponsibility for a flight.
10270000----------------------------------------------------------------------
10280000 Touch Sequemce Recaction
10290000----------------------------------------------------------------------
10300000 ASM - EXEC . Erases all upstream TID callsigns
10310000 . SDD symbol - to new controller
10320000 . Sector identity (Label and FDM)
10330000 to new controller
10340000----------------------------------------------------------------------
10370000- Cancel PLan
10390000-----------
10410000To delete all information concerning the flight plan from the system.
10420000(protected input)
10450000----------------------------------------------------------------------
10460000 Touch Sequence Reaction
10470000----------------------------------------------------------------------
10480000 CNL - Yes - EXEC . To delete all TID callsign displays
10490000 . SSD symbol - to unassumed symbol
10500000 . Sector identity - deleted from
10510000 label and FDM
10520000 . Callsign will remain displayed on
10530000 SDD until the KPL is cancelled,
10540000 provided the flight remains on
10550000 last assigned SSR code.
10560000----------------------------------------------------------------------
10590000- Allocate
10610000--------
10640000To override the automatic allocation of a flight to a controller.
10650000This order may only be used in the N-state and will not produce
10660000strips. It will have no effect on the SDDs.
10690000----------------------------------------------------------------------
10700000 Touch Sequence Reaction
10710000----------------------------------------------------------------------
10720000 - EC No. - Sector - EXEC To manually allocate
10730000 to an EC different from
10740000 automatic allocation
10750000 -------------------------------------------------------------
10760000 - S/cut - To be used to generate
10770000 ALLOC - EXEC callsign to a foreseen
10780000 sector if a route short-
10790000 cut would bring the air-
10800000 craft into the sector
10810000 before the automatic
10820000 generation of the call-
10830000 sign to both EC and PLC/
10840000 ECO (protected input)
10850000 ------------------------------------------------------------
10860000 - Recovery - EXEC To recover from a wrong
10870000 assume
10880000---------------------------------------------------------------------
10890000 The aircraft callsign
10900000 will be redisplayed to
10910000 all previous sectors
10920000 concerned with the flight
10930000 as unassumed flight.
10940000 Thereafter the flight
10950000 will be automatically
10960000 assumed, if the aircraft
10970000 is flying on an on-route
10980000 segment or has to be
10990000 manually 'assumed' by the
11000000 correct EC, if the air-
11010000 craft is flying on an
11020000 off-route segment at that
11030000 time.
11040000-----------------------------------------------------------------------
11080000- HANDOFF
...
...
...
...
...
...
..A R+ S
...
16490000- LABEL POSITION VIA ROLLING BALL
16510000-------------------------------
16540000To change label position on an aircraft for which no callsign is
16550000on the TID
...
... A R+ S
...
166800004.5 Summary of Inputs
16690000 -----------------
167100004.5.1 Inputs After Callsign
16720000 ---------------------
16750000CALLSIGN - MODETA - EARLY/LATE - 2 FIGS - EXEC
16760000 - LVL - KFL - FL - EXEC
16770000 - MFL - FL - EXEC
16780000 - KFLF - 3 FIGS - EXEC
16790000 - MFLF - 3 FIGS - EXEC
16800000 - XKFL - EXEC
16810000 - XMFL - EXEC
16830000 - STATE - M-FORCE A R+ S … … . . .
16840000 - CNLLRS - EXEC
16860000 - PSSR - 4 FIGS - EXEC
16880000 - COR - RLB - EXEC
16900000 - XCOR - EXEC
...
... A R+ S
...
171500004.5.2 Inputs After SET
17160000 ----------------
17190000SET - VEC1 - RLB - RLB - EXEC
17200000 - VEC2 - RLB - RLB - EXEC
17210000 - XVEC - EXEC
17220000 - MTD - RLB - EXEC
17230000 - TRK - RLB - RLB - EXEC
17240000 - XTRK - RLB - EXEC -
17250000 - LABPOS - RLB - EXT/NORM - LAB.DRN - EXEC
17260000 - LAB.DRN - EXEC
17270000 - AUTO - EXEC
...
... A R+ S
...
174200004.5.3 Input Availability
17430000 ------------------
17460000Sequence Planner Coord. Executive
17470000-------- ------- ------ ---------
17490000MODETA x x x
...
... A R+ S
...