============================= Zajęcia 6: Urządzenia znakowe ============================= Data: 04.04.2019 .. contents:: .. toctree:: :hidden: zadanie Materiały dodatkowe =================== - :ref:`05-zadanie` - :download:`example.tar` O urządzeniach i sterownikach w Linuksie ======================================== Sterownikiem urządzenia nazywamy zbiór kodu obsługujący jakieś urządzenie (zazwyczaj sprzętowe, ale zdarzają się urządzenia wirtualne) i eksportujący zbiór funkcji pozwalający na wykorzystanie tego urządzenia przez użytkownika. Sterownik prawie zawsze ma wyłączny bezpośredni dostęp do urządzenia. Często jest odpowiedzialny za pogodzenie ze sobą potrzeb różnych użytkowników (choć równie często jest to obsługiwane przez wyższe warstwy -- w przypadku dysku twardego za taką warstwę można uznać system plików). Sterowniki urządzeń zazwyczaj są modułami jądra. Jeśli urządzenie nie jest zbyt "blisko" wpięte w procesor, da się również napisać sterownik w przestrzeni użytkownika (urządzenia USB się do tego świetnie nadają), ale nie będziemy się tym zajmować na zajęciach. Aby udostępnić funkcjonalność sterownika dla programów użytkownika, należy użyć jednego z wielu możliwych mechanizmów komunikacji z jądrem. Najczęściej spotykane to: - plik urządzenie blokowego -- używane do dysków twardych i dostatecznie podobnych tworów (dyskietka, CD-ROM, SSD, ...). Sterownik udostępnia funkcje zapisu i odczytu bloków, a warstwa blokowa zajmuje się obsługą żądań od użytkownika (buforowanie, kolejkowanie, itp). - plik urządzenia znakowego -- używany do większości rodzajów urządzeń. Sterownik po prostu dostarcza funkcje odpowiadające wywołaniom systemowym działającym na plikach -- jądro przekazuje takie wywołania prosto do sterownika, pozwalając na implementację dowolnego interfejsu. - interfejs sieciowy -- sterownik udostępnia funkcje wysłania i odebrania pakietu, do których wpina się podsystem sieci. Użytkownik może korzystać z niego przez wywołania ``socket``. - plik w ``proc`` -- używane w przypadku sterowników z trywialnym interfejsem (np. cała funkcjonalność sterownika to odczyt/zapis jednego parametru). - plik w ``sysfs`` -- jak wyżej, ale nowszy (i prostszy) interfejs. Reprezentacja plikowa --------------------- Użycie urządzeń znakowych i blokowych odbywa się przez stworzenie odpowiadającego im pliku specjalnego gdzieś w systemie plików (prawie zawsze ``/dev``) i otwarcie go. Taki plik specjalny jest tylko "wrotami do jądra" i jedyne informacje o nim przechowywane w systemie plików to: - flagę określająca typ urządzenia (``b`` -- blokowe, ``c`` -- znakowe) - numer główny (major device number) - numer drugorzędny (minor device number) Zazwyczaj numer główny wybiera sterownik urządzenia, a numer drugorzędny wybiera konkretny egzemplarz urządzenia obsługiwany przez ten sterownik. Zdarzają się jednak przypadki, że jeden numer główny jest współdzielony przez wiele sterowników, jeśli eksportują one tylko po jednym urządzeniu. Na poziomie języka C oba numery są pakowane w jedną liczbę typu ``dev_t``. Przydatne są następujące makra (``linux/kdev_t.h``): ``int MAJOR(dev_t numer)`` zwraca numer główny urządzenia. ``int MINOR(dev_t numer)`` zwraca numer drugorzędny. ``dev_t MKDEV(int major, int minor)`` Skleja numery w typ ``dev_t``. Do utworzenia pliku urządzenia ręcznie można użyć następującego polecenia:: mknod mknod /dev/nazwa_pliku typ major minor Wpisując ``ls -l`` zobaczymy numery urządzenia tam, gdzie zazwyczaj znajduje się rozmiar pliku. W dawnych czasach, numery były przydzielane odgórnie i zsyłane przez programistów jądra na ziemię na kamiennych tablicach (``Documentation/devices.txt``). Dystrybucje Linuxa tworzyły na podstawie tych tablic gotowy katalog ``/dev`` z wszystkimi możliwymi urządzeniami (na zapas). Nie było to jednak najlepsze rozwiązanie. We współczesnych czasach, jądro eksportuje informacje o dostępnych sterownikach urządzeń na żywo w systemie plików ``sysfs``, a program ``udevd`` (lub ``systemd-udevd``) na bieżąco monitoruje te informacje i tworzy odpowiednie pliki urządzeń. Ponieważ nie ma potrzeby wcześniejszego ustalenia użytych numerów, są one alokowane dynamicznie. Aby ten mechanizm działał, sterownik musi zarejestrować swoje urządzenie w hierarchii ``sysfs``. Sterowniki urządzeń znakowych w Linuksie ======================================== Rejestracja sterowników urządzeń -------------------------------- Rejestracja sterownika odbywa się w kilku etapach: 1. Alokujemy zakres numerów urządzeń:: int alloc_chrdev_region(dev_t *first, unsigned int count, const char *name); void unregister_chrdev_region(dev_t first, unsigned int count); Tą alokację zazwyczaj wywołuje się tylko raz, w funkcji inicjalizacyjnej, alokując cały zakres numerów na zapas. 2. Przygotowujemy strukturę ``file_operations`` opisującę operacje na naszym urządzeniu. Takie struktury są zazwyczaj globalne (nie ma po co ich alokować dynamicznie). 3. Tworzymy i wypełniamy strukturę ``cdev``:: void cdev_init(struct cdev *cdev, const struct file_operations *fops); Możemy również poprosić o dynamiczne zaalokowanie struktury:: struct cdev *cdev_alloc(void); W tym wypadku należy ręcznie wypełnić pole ``ops`` wskaźnikiem na naszą strukturę (nie należy mieszać tego wywołania z ``cdev_init``). 4. Rejestrujemy naszą strukturę ``cdev``:: int cdev_add(struct cdev *p, dev_t dev, unsigned count); void cdev_del(struct cdev *p); W tym momencie nasze urządzenie staje się dostępne dla przestrzeni użytkownika, gdy tylko otworzy on odpowiedni plik specjalny. Możemy podpinać urządzenia pojedynczo, bądź ciągłymi zakresami (parametr ``count``). Jeśli struktura ``cdev`` była stworzona przez ``cdev_alloc``, struktura zostanie automatycznie zwolniona przez ``cdev_del``. Jeśli natomiast była inicjowana przez ``cdev_init``, zwolnienie jej jest sprawą sterownika. Należy zauważyć, że ``cdev_del`` tylko odpina urządzenie z tablicy urządzeń, ale nie gwarantuje, że nikt już go nie używa - wcześniej otwarte deskryptory plików dalej będą działać (choć jeśli jesteśmy w ``module_exit``, mamy gwarancję że takich deskryptorów nie ma). W przypadku implementacji np. urządzenia, które powinno obsługiwać hot-unplug trzeba samemu zapewnić np. zliczanie referencji. 5. Rejestrujemy klasę urządzeń w ``sysfs`` (bądź używamy istniejącej, jeśli pasuje):: struct class moja_klasa = { .name = "abc", .owner = THIS_MODULE, }; int class_register(struct class *class); void class_unregister(struct class *class); To wykonujemy tylko raz na wszystkie nasze urządzenia (bądź na typ urządzeń, jeśli mamy wiele). 6. Rejestrujemy nasze urządzenie w ``sysfs``:: struct device *device_create(struct class *cls, struct device *parent, dev_t devt, void *drvdata, const char *fmt, ...); void device_destroy(struct class *cls, dev_t devt); ``parent`` wskazuje na urządzenie, do którego nasze urzadzenie jest podłączone -- katalog w sysfs odpowiadający naszemu urządzeniu będzie podkatalogiem katalogu podanego urządzenia. W przypadku sterowników urządzeń znakowych odpowiadających np. urządzeniom PCI, parent będzie ustawiony na pole ``dev`` struktury ``pci_device``. Można ustawić ten parametr na ``NULL``, aby otrzymać urządzenie najwyższego poziomu. ``drvdata`` może służyć do przechowywania dodatkowych informacji prywatnych dla naszego sterownika (przydatne jeśli np. chcemy stworzyć pliki w sysfs do kontroli naszego urządzenia). ``fmt`` i dalsze parametry przekazywane są do ``sprintf`` w celu stworzenia nazwy urządzenia, która pojawi się w ``/dev``. W tym momencie, ``udevd`` dostanie powiadomienie o powstaniu nowego urządzenia i (w skończonym czasie) stworzy odpowiedni plik w ``/dev``. Struktura ``file_operations`` ----------------------------- Struktura ``file_operations`` (zdefiniowana w ``linux/fs.h``) opisuje jak wykonywać operacje na danym pliku. Każdy plik (i w ogólności wszystko, co może być otwartym deskryptorem) w Linuksie ma taką strukturę -- w przypadku zwykłych plików, jest dostarczana przez sterownik systemu plików. W przypadku urządzeń znakowych, dostarcza ją sterownik urządzenia. Ma bardzo wiele pól (odpowiadających operacjom), z których najważniejsze to:: struct file_operations { struct module *owner; loff_t (*llseek) (struct file *, loff_t, int); ssize_t (*read) (struct file *, char __user *, size_t, loff_t *); ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *); int (*unlocked_ioctl) (struct file *, unsigned int, unsigned long); int (*compat_ioctl) (struct file *, unsigned int, unsigned long); int (*mmap) (struct file *, struct vm_area_struct *); int (*open) (struct inode *, struct file *); int (*release) (struct inode *, struct file *); /* ... */ }; Pole ``owner`` musimy wypełnić wskaźnikiem ``THIS_MODULE`` -- umożliwia to jądru automatyczne zarządzanie licznikiem odwołań do modułu. Pola struktury ``file`` ----------------------- Struktura ``file`` (zdefiniowana w ``linux/fs.h``) reprezentuje w jądrze otwarty plik. Jest tworzona przez jądro w momencie wywołania ``open`` i przekazywana do wszystkich operacji na pliku, aż do ostatniego wywołania ``close`` (czyli momentu, kiedy wywołane zostanie ``release``). Warto zauważyć, że otwarty plik (struktura ``file``) to co innego, niż plik na dysku (reprezentowany przez strukturę ``inode``). Najważniejsze pola tej struktury to:: struct file { mode_t f_mode; loff_t f_pos; unsigned int f_flags; struct file_operations *f_op; void *private_data; /* ... */ }; Pole ``f_mode`` pozwala określić, czy plik jest otwarty do odczytu (``FMODE_READ``), zapisu (``FMODE_WRITE``) lub obu. Pola tego nie trzeba sprawdzać w funkcjach ``read`` i ``write``, bo jądro wykonuje taki test przed wywołaniem odpowiedniej funkcji sterownika. Pole ``f_pos`` określa pozycję do pisania lub odczytu (używana przez ``read``, ``write``, ``lseek`` itp). Flagi ``f_flags`` wykorzystuje się głównie do sprawdzenia, czy operacja ma być blokująca, czy nie (``O_NONBLOCK``), choć zawiera dużo więcej flag. Pole ``f_op`` określa zestaw funkcji implementujących operacje na pliku. Pole to jest ustawiane (na operacje ze struktury ``cdev``) przez jądro przy wywołaniu ``open``, a następnie jest używane do wszystkich następnych operacji (sterownik może podmienić wartość tego pola w ``open``, aby wybrać alternatywny zestaw funkcji). Wskaźnik ``private_data`` jest ustawiany na ``NULL`` przy otwieraniu pliku. Sterownik może wykorzystać ten wskaźnik dla własnych celów (wtedy jest odpowiedzialny za zwolnienie pamięci przydzielonej na rzecz tego pola). Operacja ``open`` -- otwarcie pliku ----------------------------------- Prototyp tej funkcji wyglada następująco:: int open(struct inode *inode, struct file *filp) Operacja ``open`` umożliwia sterownikowi przeprowadzenie czynności przygotowawczych przed innymi operacjami. Zazwyczaj wykonuje się nastepujące kroki: - sprawdzenie błędów związanych z urządzeniem (np. sprawdzenie, czy urządzenie jest gotowe); - inicjalizacja urządzenia jeślijest otwierane po raz pierwszy i stosujemy leniwą inicjalizację; - identyfikacja numeru drugorzędnego (``MINOR(inode->i_rdev)``) i, jeśli jest to konieczne, podmiana zestawu operacji wskazywanej przez ``f_op``; - przydzielenie pamięci na dane związane z urządzeniem, inicjalizacja struktur danych oraz przypisanie wskaźnika ``private_data``; Operacja ``release`` -- zamknięcie pliku ---------------------------------------- Jądro trzyma licznik referencji dla każdej istniejącej struktury ``file``. Może być zwiększony np. przez wywołanie ``dup`` bądź dziedziczenie otwartego pliku przez ``fork``. Gdy ten licznik w końcu spadnie do 0 (zostanie wywołany ``close`` na ostatnim deskryptorze, bądź proces trzymający ten deskryptor wywoła ``exit``), zostanie wywołana funkcja ``release``, służąca za destruktor pliku:: int release(struct inode *inode, struct file *filp) Jej zadaniem jest zwolnienie zasobów alokowanych w operacji ``open`` i wykonanie podobnych czynności sprzątających: - zwolnienie pamięci ``private_data``; - wyłączenie urządzenia, gdy jest to ostatnie wywołanie ``release``; Operacje ``read`` i ``write`` -- transfer danych ------------------------------------------------ Prototyp tej funkcji wyglada następująco:: ssize_t read(struct file *filp, char __user *buff, size_t count, loff_t *offp) ssize_t write(struct file *filp, const char __user *buff, size_t count, loff_t *offp) Zadaniem operacji ``read`` jest przepisanie pewnej porcji danych z przestrzeni adresowej jądra pod wskazany adres (``buff``) w przestrzeni adresowej użytkownika. Operacja ``write`` działa w odwrotnym kierunku. Funkcje te są używane do implementacji wielu wywołań systemowych (``read``, ``pread``, ``readv``, ...). ``offp`` jest wskaźnikiem na bieżącą pozycję w pliku. Jeśli w przypadku naszego pliku taka pozycja ma sens, bierzemy ją z tego miejsca i wpisujemy tu zaktualizowaną wartośc pozycji. W przypadku zwykłego ``read`` i ``write`` będzie to wskaźnik na ``filp->f_pos``, a w przypadku ``pread`` i ``pwrite`` będzie to wskaźnik na jakąś zmienną na stosie zawierającą parametr wywołania systemowego. Wartość zwracana przez tę funkcję będzie interpretowana następująco: - wartość większa od zera oznacza liczbę przepisanych bajtów; jeśli jest równa wartości argumentu przekazanego do wywołania systemowego, to oznacza pełen sukces, jeśli zaś mniejsza, to oznacza, że tylko część danych została przekazana - należy się wtedy spodziewać, że program powtórzy wywołanie systemowe (takie jest np. standardowe zachowanie funkcji bibliotecznej ``fread``/``fwrite``) - jeśli wartość jest równa ``0`` to został osiągnięty koniec pliku (używane tylko w ``read``) - wartość ujemna oznacza błąd Implementując te operacje, należy pamiętać o zachowaniu właściwej semantyki -- zwrócenie błędu mówi, że żadne bajty nie zostały odczytane/zapisane. Jeśli nasz sterownik zauważy błąd dopiero po pewnej ilości przetransferowanych bajtów (i nie ma łatwego sposobu, by ten transfer cofnąć), należy zamiast błędu zwrócić liczbę przetransferowanych bajtów -- kod błędu będzie zwrócony gdy użytkownik ponowi operację dla pozostałych bajtów. Operacja ``llseek`` -- zmiana pozycji pliku ------------------------------------------- Prototyp tej funkcji wyglada następująco:: loff_t llseek(struct file *filp, loff_t off, int whence) Operacja ``llseek`` implementuje wywołania systemowe ``lseek`` i ``llseek``. Domyślnym działaniem jądra, gdy operacja ``llseek`` nie jest wyszczególniona w operacjach sterownika, jest zmiana pola ``f_pos`` struktury file. W przypadku, gdy pojęcie zmiany pozycji pliku nie ma sensu dla urządzenia, należy wpisać tu funkcję zwracającą błąd. W jądrze jest w tym celu dostępna gotowa funkcja ``no_llseek``, zawsze zwracająca ``-ESPIPE``. Operacja ``ioctl`` -- wywołanie komend specyficznych dla urządzenia ------------------------------------------------------------------- Prototypy funkcji wygladają następująco:: long (*unlocked_ioctl) (struct file *filp, unsigned int cmd, unsigned long arg); long (*compat_ioctl) (struct file *filp, unsigned int cmd, unsigned long arg); Funkcja ``unlocked_ioctl`` odpowiada wywołaniom ``ioctl`` przez "główną" architekturę jądra. Nazwa jest zaszłością historyczną z czasów big kernel locka -- niegdyś sterowniki urządzeń wymagające big kernel locka wypełniały pole ``ioctl``, podczas gdy nowsze lub skonwertowane sterowniki używające własnych blokad używały ``unlocked_ioctl``. W obecnych wersjach jądra big kernel lock i pole ``ioctl`` już nie istnieją. Funkcja ``compat_ioctl`` odpowiada wywołaniom ``ioctl`` przez programy użytkownika w trybie zgodności z 32-bitową wersją architektury -- np. programy na architekturę i386 pod jądrem na architekturę x86_64. W przypadku, gdy struktury przekazywane przez ``ioctl`` nie zawierają pól o rozmiarze zależnym od architektury, można ustawić oba pola na tą samą funkcję. Pierwszy argument odpowiada deskryptorowi pliku przekazanemu przez wywołanie systemowe. Argument ``cmd`` jest dokładnie taki, jak w wywołaniu systemowym. Opcjonalny argument ``arg`` jest przekazywany w postaci liczby typu ``unsigned long`` bez względu na typ użyty przy wywołaniu systemowym. Zazwyczaj implementacja operacji ``ioctl`` zawiera po prostu konstrukcję switch wybierającą odpowiednie zachowanie w zależności od wartości argumentu ``cmd``. Różne komendy są reprezentowane różnymi numerami, którym zazwyczaj nadaje się nazwy korzystając z definicji preprocesora. Program użytkownika powinien mieć możliwość włączenia pliku nagłówkowego z deklaracjami (zazwyczaj tego samego, który jest używany przy kompilacji modułu sterownika). Do twórcy interfejsu sterownika należy ustalenie wartości liczbowych odpowiadających komendom interpretowanym przez sterownik. Najprostszy wybór, przypisujący kolejne małe wartości poszczególnym komendom, niestety ogólnie nie jest dobrym rozwiązaniem. Komendy powinny być unikalne w skali systemu, żeby uniknąć błędów, gdy poprawną komendę wysyłamy do niepoprawnego urządzenia. Taka sytuacja może nie występować zbyt często, ale jej konsekwencje mogą by poważne. Przy różnych komendach dla wszystkich ``ioctl``, w przypadku pomyłki, zostanie zwrócone ``-ENOTTY`` zamiast wykonania niezamierzonej akcji. W ustalaniu wartości liczbowych dla komend powinno się używać następujących makr (zdefiniowanych w ``linux/ioctl.h``): ``_IO(type, nr)`` komenda ogólnego przeznaczenia (bez argumentu) ``_IOR(type, nr, dataitem)`` komenda z zapisem w przestrzeni użytkownika ``_IOW(type, nr, dataitem)`` komenda z odczytem z przestrzeni użytkownika ``_IOWR(type, nr, dataitem)`` komenda z zapisem i odczytem Oznaczenia: ``type`` unikatowy numer dla sterownika (8 bitów, wybrany po przejrzeniu ``Documentation/ioctl-number.txt``) -- numer magiczny ``nr`` kolejny numer komendy (8 bitów) ``dataitem`` struktura związana z komendą; rozmiar podanej struktury zazwyczaj nie może byc większa niż 16kb-1 (zależy to od wartości ``_IOC_SIZEBITS``). Kodowanie rozmiaru struktury zapisywanej/odczytywanej jako parametr może się przydać do wyłapywania programów skompilowanych z nieaktualnymi wersjami sterownika i pozwala uniknąć np. pisania poza buforem. Przykład:: #define DN_SETCOUNT _IOR(0, 3, int) Funkcje przydatne przy programowaniu w trybie jądra =================================================== Informacje o procesie --------------------- Podczas pisania kodu, który będzie się wykonywał w przestrzeni adresowej jądra należy cały czas pamiętać, że wątek wykonania jest związany z pewnym procesem użytkownika, w imieniu którego jądro wykonuje określone operacje. Korzystając z makra ``current`` (``asm/current.h``) możemy łatwo (i szybko) dotrzeć do wszystkich informacji jakie jądro przechowuje o bieżącym procesie w strukturze task_struct (``linux/sched.h``). Wyjątkiem jest obsługa przerwań - o ile w trakcie wykonywania funkcji obsługi przerwania sprzętowego, makro ``current`` może wskazywać na jakiś proces, to nie należy się do niego odwoływać (nie ma on związku z tym przerwaniem) jak również nie wolno przełączać się na inne procesy (czyli nie można też wykonywać operacji blokujących). Ćwiczenie: Proszę zapoznać się z definicją struktury task_struct i spróbować wyjaśnić znaczenie innych jej pól (``linux/sched.h``). Proste blokady -------------- Ze względu na częstą w jądrze konieczność używania danych wspólnych dla wielu procesów, jedną z najważniejszych klas funkcji w jądrze stanowią funkcję synchronizujące wywołanie procesów, m.in. blokady. Najprostszym rodzaj blokad są zwykłe blokady (nazywane też mutexami). Ten rozaj blokad jest zdefiniowany w ``linux/mutex.h``. Taka blokada nie jest rekurencyjna i musi zostać zwolniona przez proces, którą ją założył. Proces próbujący zablokować już zablokowaną blokadę będzie spał (przechodząc w stan S lub D) aż blokada zostanie zwolniona. Blokady tworzy się w jeden z następujących sposobów:: /* dla blokad będących zmiennymi globalnymi */ static DEFINE_MUTEX(blokada); :: /* dla blokad w strukturach alokowanych dynamicznie */ struct mutex blokada2; /* ... */ mutex_init(&blokada2); Dostępne są między innymi następujące operacje:: void mutex_lock(struct mutex *lock); int mutex_lock_interruptible(struct mutex *lock); int mutex_lock_killable(struct mutex *lock); int mutex_trylock(struct mutex *lock); Funkcje zakładające blokadę. Pierwsza nie przyjmuje żadnych sygnałów w czasie ewentualnego oczekiwania na zwolnienie blokady. Druga pozwala na odebranie sygnału (zwraca ``-EINTR`` w przypadku pobudki wywołanej sygnałem, ``0`` wpp.). Trzecia działa jak druga, ale jest przerywalna tylko przez sygnały, które spowodują zabicie procesu. Trzecia funkcja nie oczekuje na zwolnienie blokady - w przypadku gdy blokada jest już zablokowana, zwraca ``-EAGAIN`` i nic nie robi, w przypadku udanego zablokowania zwraca ``0``. :: void mutex_unlock(struct mutex *lock); Zwalnia blokadę i budzi jeden z ewentualnych procesów oczekujących. Pozostałe typy blokad i inne funkcje synchronizujące będą omówione na następnych zajęciach. Wymiana danych między przestrzenią adresową użytkownika i jądra --------------------------------------------------------------- Aby z poziomu jądra odczytać/zapisać coś z/do przestrzeni pamięci programów użytkownika należy posłużyć się następującymi funkcjami (właściwie makrami): ``put_user(kptr, ptr)`` wpisanie bajtu/słowa/długiego słowa do pamięci programów użytkownika (spod adresu ``ptr``); makrodefinicja działa automagicznie - rozmiar określony jest na podstawie typu, na który wskazuje ``kptr`` ``get_user(kptr, ptr)`` j.w., ale odczytanie Do kopiowania większych obszarów pamięci służą funkcje:: unsigned long copy_from_user(void *to, const void __user *from, unsigned long n); unsigned long copy_to_user(void __user *to, const void *from, unsigned long n); Pierwsza umożliwia kopiowanie danych z przestrzeni adresowej użytkownika do przestrzeni adresowej jądra, druga odwrotnie. Ogólnie zachowują się jak ``memcpy``, jednak trzeba pamiętać, że w przypadku błędu braku strony adresu w przestrzeni użytkownika mogą spowodować uśpienie procesu aż do momentu ściągnięcia strony z pliku wymiany. Przed kopiowaniem sprawdzana jest poprawność adresu w przestrzeni użytkownika. Jeśli początek obszaru jest poprawny, ale dalsza część nie, to kopiowany jest najdłuższy możliwy fragment. Wartością zwracaną przez obie funkcje jest liczba NIE skopiowanych bajtów - niezerowa oznacza wystąpienie błędu przy kopiowaniu. Funkcje i odpowiadające im makrodefinicje zdefiniowane są w pliku ``asm/uaccess.h``. Należy zwrócić uwagę, iż funkcje dla bloków o rozmiarze potęg dwójki są zoptymalizowane. W przypadku błedu przy kopiowaniu z/do przestrzeni użytkownika, syscalle powinny zwracać ``-EFAULT``. Wykorzystanie standardowej implementacji list --------------------------------------------- Jądro zawiera efektywną implementację list dwukierunkowych. Lista składa się z cyklicznie połączonych struktur ``list_head``, najczęściej będących składowymi jakiejś większej struktury. Należy zauważyć, że zarówno głowa listy jak i jej elementy są strukturami ``list_head`` -- wykrywanie końca listy następuje przez porównanie z adresem głowy. Wszystkie operacje na listach dostępne są poprzez plik ``linux/list.h``. Oto garść pojęć związanych z listami: ``list_head`` struktura reprezentująca głowę (cząstkę) listy ``LIST_HEAD(lista)`` makro definiujące i inicjalizujące zmienną z głową listy ``INIT_LIST_HEAD(lista)`` makro inicjalizujące głowę listy (dla list tworzonych dynamicznie) ``list_add(co, do_czego)`` dodanie ``co`` na początek ``do_czego`` ``list_add_tail(co, do_czego)`` dodanie ``co`` na koniec ``do_czego`` ``list_del(co)`` usunięcie ``co`` z listy ``list_empty(lista)`` sprawdzenie, czy lista jest pusta ``list_splice(co, przed_co)`` sklejenie listy ``co`` oraz ``przed_co`` ``list_for_each(kazdy, po_liscie)`` iteracja zmiennej ``kazdy`` po każdym elemencie ``po_liscie`` ``list_for_each_safe(kazdy, tymczasem, po_liscie)`` iteracja zmiennej ``kazdy`` po każdym elemencie ``po_liscie`` w sposób bezpieczny ze względu na usuwanie elementów listy (w tym celu wykorzystuje się zmienną ``tymczasem``) ``list_entry(moja_lista, struktura, pole)`` wyliczenie wskaźnika na początek struktury, ktorej pole typu ``list_head`` jest ``moja_lista`` Po szczegóły odsyłam do kodu źródłowego. Literatura ---------- 1. A. Rubini, J. Corbet, G. Kroah-Hartman, Linux Device Drivers, 3rd edition, O'Reilly, 2005. (http://lwn.net/Kernel/LDD3/) 2. Książki podane na stronie przedmiotu: http://students.mimuw.edu.pl/ZSO/ .. ============================================================================= Autor: Grzegorz Marczyński (g.marczynski@mimuw.edu.pl) Aktualizacja: 2003-03-13 Aktualizacja: 2004-10-20 Stanisław Paśko (sp@mimuw.edu.pl) Aktualizacja: 2005-10-22 Piotr Malinowski (malinex@mimuw.edu.pl) Aktualizacja: 2006-11-16 Radek Bartosiak (kedar@mimuw.edu.pl) - linux 2.6 Aktualizacja: 2012-03-18 Marcin Kościelnicki (m.koscielnicki@mimuw.edu.pl) Aktualizacja: 2013-03-25 Marcin Kościelnicki (m.koscielnicki@mimuw.edu.pl) =============================================================================