Obsluha přerušení, výjimek a systémových volání.

Zdroj: [link]

Přerušení

metoda pro asynchronní obsluhu událostí, kdy procesor přeruší vykonávání sledu instrukcí, vykoná obsluhu přerušení a pak pokračuje.

vnitřní - vyvolané procesorem (problém se zpracováním instrukcí, dělení 0, výpadek stránky)

Také nazývané synchronní, a to proto, že CPU jej vyvolá až po dokončení aktuálně vykonávané instrukce, Intelovský manuál je nazývá Exception

vnější - hardwarové, přichází z V/V zařízení, mají přidělena čísla IRQ (Interrupt Request)

pro signalizaci přerušení– kanály přerušení, reprezentovány čísly IRQ, na jednom IRQ kanálu může být napojeno více zařízení (= sdílený kanál, sdílené IRQ) 

Také nazývané asynchronní, a to proto, že závisí na ticích časovače a může nastat v době kdy CPU právě vykonává nějakou instrukci, Intelovský manuál je nazývá Interrupt

Další dělení je na maskovatelná a nemaskovatelná

 Maskable interrupts: All Interrupt Requests (IRQs) issued by I/O devices give rise to maskable interrupts . A maskable interrupt can be in two states: masked or unmasked; a masked interrupt is ignored by the control unit as long as it remains masked.

 Nonmaskable interrupts: Only a few critical events (such as hardware failures) give rise to nonmaskable interrupts . Nonmaskable interrupts are always recognized by the CPU.

Přerušení mají priority - obsluha přerušení může být přerušena přerušením s vyšší prioritou :) - pozn. Priority z hlediska kernelu jsou jen low a high, tedy přerušitelné a nepřerušitelné. APIC (Advanced Programmable Interrupt Controller ale priority podporuje, takže priority přerušení jako takové Linux nikde neřeší, ale nechává to na hardware (APIC je v každém CPU).

Přerušení je obecně asynchronní vzhledem k přerušenému procesu 

Zpracování přerušení nesmí způsobit čekání, přerušený proces zůstává ve stavu běžící 

čas zpracování přerušení je započítán přerušenému procesu, při zpracování se tedy přistupuje do jeho záznamu proc

1) uloží IRQ (Interrupt ReQuest) a obsah registrů

2) pošle potvrzení PIC (Programmable Interrupt Controller), který zajišťuje provoz přerušení

3) modul pro obsluhu přerušení (Interrupt Handler) vykoná obsluhu přerušení

4) ukončí skokem na ret_from_intr()

synchronní s procesem (vznikají v důsledku událostí způsobených vykonáváním procesu)

Stejné jako u přerušení, 80x86 procesory mají přibližně 20 definovaných výjimek, každá je zpracována přiřazeným exception handlerem - ten většinou nedělá nic jiného než že pošle signál procesu, který výjimku způsobil, kernel musí poskytnout exception handler pro každou definovanou výjimku, příklady výjimek i s jejich číslem: 0 - Divide Error = dělení nulou, 1 - Debug, 4 - Overflow = přetečení…

1) uloží obsah registrů

pošle signál procesu

zpracuje žádost o stránku

3) ukončí se voláním funkce ret_from_exception()

Vektor přerušení

 - 0-31 vnitřní přerušení (výjimky), 32 - 255 IRQ přerušení

Vektor přerušení u x86 se nazývá IDT (Interrupt Descriptor Table) - tabulka, která přiřazuje obslužnou rutinu ke každému přerušení

mechanismus pro volání funkcí operačního systému aplikacemi

v standardní knihovně jazyka C je pro každé systémové volání obálková procedura, řízení se předá softwarovým přerušením proceduře jádra syscall()

system_call - jedna pro všechny služby, požadovaná služba se odlišuje parametrem procedury, který se nazývá číslo systémového volání

1) uloží obsah registrů (HW kontext)

3) ukončí se voláním ret_from_sys_call()

Int 0x80 je legacy instrukce, funguje jen u 32 bit systému a dnes se nepoužívá

VDSOs (Virtual Dynamically linked Shared Objects) are a way to export kernel space routines to user space applications, using standard mechanisms for linking and loading (i.e. standard ELF format).

It helps to reduce the calling overhead on simple kernel routines, and also can work as a way to select the best system call method on some architectures.

An advantage over other methods is that such exported routines can provide proper DWARF debugging information.

(z diskuse [link])
