• Termen de predare:
  • Sâmbătă, 25 Aprilie 2020, ora 23:00 (pentru Ixia Challenge - 2p)
  • Dumincă, 03 Mai 2020, ora 23:00 (deadline hard - 1.5p)

Să se scrie un modul de kernel care să implementeze sistemul de fișiere PITIX, versiunea 2. Acest sistem de fișiere va oferi suport doar pentru fișiere și directoare. Nu se vor implementa operațiile de suport pentru link-uri hard sau simbolice. De asemenea, nu se vor implementa operațiile de suport pentru fișiere speciale (pipe-uri, dispozitive caracter sau bloc). Practic va trebui să implementați următoarele operații:

• pentru directoare: lookup, unlink, mkdir, rmdir, iterate
• pentru fișiere: create, truncate, funcția de bitmap (vezi minix_get_block)

Restul funcțiilor fie au implementări generice în kernel, fie nu trebuie să le implementați.

Structura pe disk a sistemului de fișiere este:

unde:

• Superblock conține superblocul (4096 octeți)
• Imap conține harta de biți (bitmap) a blocurilor ocupate de inode-uri (1 bloc)
• Dmap conține harta de biți (bitmap) a blocurilor ocupate de date (1 bloc)
• Izone conține inode-urile (32 blocuri)
• Dzone conține datele (conținutul efectiv al fișierelor) (8*block_size blocuri)

Superblocul (pe disc) este descris de următoarea structură:

struct pitix_super_block {
        unsigned long magic;
        __u8 version;
        __u8 block_size_bits;
        __u8 imap_block;
        __u8 dmap_block;
        __u8 izone_block;
        __u8 dzone_block;
        __u16 bfree;
        __u16 ffree;
};

unde

• magic trebuie să fie inițializat cu PITIX_MAGIC
• version trebuie să fie inițializat cu 2 (PITIX_VERSION)
• block_size_bits este dimensiunea blocului în puteri ale lui doi; dimensiunea blocului poate să fie 512, 1024, 2048, sau 4096
• imap_block este numărul blocului (relativ la dispozitiv) pentru vectorul de biți folosit pentru alocarea/eliberarea inode-urilor
• dmap_block este numărul blocului (relativ la dispozitiv) pentru vectorul de biți folosit pentru alocarea/eliberarea blocurilor de date
• izone_block este numărul primului bloc (relativ la dispozitiv) al zonei de inode-uri
• dzone_block este numărul primului bloc (relativ la dispozitiv) al zonei de date
• bfree este numărul de blocuri libere (nealocate)
• ffree este numărul de inode-uri libere (nealocate)

Inode-urile vor fi stocate în zona de inode-uri și sunt descrise de următoarea structură:

struct pitix_inode {
        __u32 mode;
        uid_t uid;
        gid_t gid;
        __u32 size;
        __u32 time;
        __u16 direct_data_blocks[INODE_DIRECT_DATA_BLOCKS];
        __u16 indirect_data_block;
};

unde

• mode reprezintă drepturile de acces și tipul inode-ului (fișier sau director) așa cum sunt reprezentate în kernel
• uid reprezintă UID-ul așa cum este el reprezentat în kernel
• gid reprezintă GID-ul așa cum este el reprezentat în kernel
• size reprezintă dimensiunea fișierului/directorului
• time reprezintă timpul de modificare așa cum este el reprezentat în kernel
• direct_data_blocks este un vector (de dimensiune INODE_DIRECT_DATA_BLOCKS) ce conține indecșii blocurile de date directe
• indirect_data_block este indexul unui bloc de date ce conține indecșii blocurilor de date indirecte

Indexul unui bloc de date (direct sau indirect) indică numărul acelui bloc de date relativ la zona de date (Dzone). Dimensiunea unui index este de 2 octeți.

După cum se vede din structura sa, inode-ul folosește o schemă de indirectare simplă pentru blocurile de date. Blocurile din intervalul [0, INODE_DIRECT_DATA_BLOCKS) sunt blocuri de date directe și sunt referite de elementele vectorului direct_data_blocks iar blocurile din intervalul [INODE_DIRECT_DATA_BLOCKS, INODE_DIRECT_DATA_BLOCKS + block_size / 2) sunt blocuri de date indirecte și sunt referite de indecșii din cadrul blocului de date indicat de indirect_data_block.

Blocul de date indicat de indirect_data_block trebuie alocat atunci când avem de referit un prim bloc de date indirect și trebuie eliberat atunci când nu mai sunt blocuri de date indirecte.

Indecșii nefolosiți trebuie setați pe 0. Primul bloc, cel cu index 0, este tot timpul alocat când se face formatarea. Acest bloc nu va putea fi folosit și, în consecință, valoarea 0:

• într-un element din vectorul direct_data_blocks înseamnă slot liber (acel element nu referă un bloc de date direct)
• pentru indirect_data_block înseamnă că nu este alocat un bloc de date pentru a ține evidența blocurilor de date indirecte (atunci când nu sunt necesare blocuri de date indirecte)
• pentru un index din cadrul blocului de date referit de indirect_data_block înseamnă slot liber (acel index nu referă un bloc de date indirect)

Este garantat faptul că numărul de octeți ocupați de un inode pe disc este divizor al dimensiunii blocului.

Directoarele au asociate un singur bloc de date (referit prin direct_data_block[0]) în care vor fi stocate intrările de director. Acestea sunt descrise de următoarea structură:

struct pitix_dir_entry {
        __u32 ino;
        char name[PITIX_NAME_LEN];
};

unde

• ino reprezintă numărul inode-ului fișierului sau directorului; acest număr este un index în zona de inode-uri
• name reprezintă numele fișierului sau al directorului; lungimea maximă a numelui este 16 octeți (PITIX_NAME_LEN); dacă lungimea numelui e mai mică decât 16 octeți, atunci numele va fi terminat cu caracterul ASCII ce are codul 0 (la fel ca la șirurile de caractere)

Directorul rădăcină va avea alocat inode-ul 0 și blocul de date 0.

Pentru simplificare, la mkdir nu este necesară crearea intrărilor . (dot) și .. (dot dot) în noul director; checker-ul se folosește de această presupunere.

Toate valorile numerice sunt stocate pe disc în CPU byte-order.

În header-ul temei găsiți structurile descrise anterior împreună cu unele macro-uri utile și declarațiile principalelor funcții de implementat.

Modulul de kernel va avea numele pitix.ko.

Pentru simplificarea procesului de corectare a temelor, dar și pentru a reduce greșelile temelor trimise, corectarea temelor se va face automat cu ajutorul testelor publice care se găsesc în noua infrastructură. Pentru testarea locală, folosiți următoarele comenzi:

$ git clone https://github.com/linux-kernel-labs/linux.git
$ cd linux/tools/labs
$ LABS=assignments/5-pitix make skels 
# dezvoltarea temei se va efectua în directorul 5-pitix/
$ make build
$ make copy
$ make boot

Indicații despre utilizarea suitei de teste se găsesc în fișierul README din cadrul arhivei.

Pentru a vă mări șansele de a obține nota maximă, citiți și respectați coding style-ul kernelului Linux descris din documentul Coding Style.

De asemenea, folosiți următoarele tool-uri de analiza statică pentru a verifica codul:

•  /path/to/linux-4.9.11/scripts/checkpatch.pl --no-tree --terse -f /path/to/your/src-file.c 

•  sudo apt-get install sparse 

•  cd /path/to/linux-4.9.11 
   make C=2 /path/to/your/src-file.c 

•  sudo apt-get install cppcheck 

•  cppcheck /path/to/your/src-file.c 

Datorită nivelului de dificultate mai ridicat, tema valorează două puncte.

Depunctările generale pentru teme se găsesc pe pagina de Indicații generale.

În cazuri excepționale (tema trece testele prin nerespectarea cerințelor) și în cazul în care tema nu trece toate testele se poate scădea mai mult decât este menționat mai sus.

Arhiva temei va fi submisă pe vmchecker, în conformitate cu precizările din pagina de reguli.

Din interfața vmchecker alegeți opțiunea Sistem de fișiere, aferentă acestei teme.

• header-ul temei
• Laboratorul 8. Drivere sisteme de fișiere (partea întăi)
• Laboratorul 9. Drivere sisteme de fișiere (partea a doua)
• Sursele sistemului de fișiere Minix

Pentru întrebări legate de temă puteți consulta arhivele listei de discuții sau puteți trimite un e-mail (trebuie să fiți înregistrați).

Vă rugăm să urmăriți și să respectați indicațiile de utilizare a listei.