2011-09-22 9 views
6

Każdy proces ma tabelę deskryptorów plików (FDT), a każdy plik ma deskryptor pliku. Deskryptory plików dla stdin, stdout i stderr to 0,1, a 2. Te wartości są takie same dla wszystkich procesów. FDT Wierzę, że zawiera odniesienia do wpisów INODE tych plików. Deskryptory plików są ponownie wykorzystywane w różnych procesach, tj. Nie są globalnie unikalne. Czy istnieje globalny FDT konserwowany przez jądro, do którego odnosi się każdy proces "FDT? Co odpowiada FDT dla stdin, stdout i stderr? Czy te specjalne pliki są powiązane z klawiaturą, wyświetlaczem itp. Proszę podać linki do artykułów, książek itp.Pomoc dotycząca deskryptorów plików w systemie Unix

Odpowiedz

7

Dobrym punktem wyjścia jest artykuł "A small trail through the Linux kernel" z 2001 roku. Mechanizmy są nadal podobne, choć wdrożenie zostało przeniesione i najlepiej studiować w a more recent kernel.

Wewnątrz jądra każdy otwarty deskryptor pliku odpowiada struct file, który zawiera wszystkie informacje o otwartym pliku lub urządzeniu. Deskryptor pliku nie jest niczym więcej jak indeksem do FDT dla procesu. W jądrze Linuksa struct file jest dołączony do FDT przez funkcję fd_install(). struct file można ponownie przypisać do innego deskryptora pliku przez dup2 system call.

Procesy mogą współużytkować ten sam FDT, jeśli procesy zostały utworzone przez wywołanie systemowe clone z flagą CLONE_FILES, ale nie ma globalnego FDT. Normalna operacja fork tworzy nowy FDT będący kopią macierzystego FDT. Praktyczne zastosowanie tego jest dla każdego wątku wielowątkowej aplikacji jako sklonowanego procesu dzielącego wspólny FDT, zapewniając, że wszystkie wątki mogą używać tych samych deskryptorów plików całkowitych. Jeśli utworzysz nowy proces przy użyciu fork/exec, nowy proces rozpocznie się od tych samych deskryptorów plików, ale może otwierać i zamykać pliki bez wpływu na element nadrzędny.

Wpisy FDT dla stdin, stdout, stderr są dziedziczone z rodzica. Nie ma nic szczególnego w ich implementacji jądra tych trzech wpisów FDT; ich znaczenie pochodzi z konwencjonalnego użycia biblioteki C. Sam proces nadrzędny decyduje o tym, z czym są połączeni. Mogą łączyć się z urządzeniami znakowymi lub mogą być podłączone do plików lub do potoków. W przypadku urządzenia znakowego najbardziej normalnym jest urządzenie tty lub pty. Darmowa książka z tych Linux Device Drivers ma a good overview.

+1

Pod koniec akapitu 3, myślę, że masz na myśli, że proces potomny może otwierać i zamykać pliki * bez * wpływu na rodzica –

Powiązane problemy