Autor: trashcan man (trash_at_military.milnet.pl)
Data: Thu 28 Dec 2000 - 07:13:23 MET
On 27 Dec 2000 14:20:55 +0100, Gotfryd Smolik - listy dyskusyjne wrote:
> Kernela Linuxa też nie czytałem -:), ale wzbudziłeś we mnie
> ciekawość: "czyste C" ma oznaczać "zgodne z ANSI" (IMHO trudno
> zrobić [kernel w ANSI C] i już ;>) ?
zgodne z ansi + rozszerzenia gnu.
> Dla jasności: gdzieniegdzie C jest supportowanym językiem
> do pisania driverów i innych takich (choćby OS z sygnatury)
> ale używa własnych rozszerzeń -:) Jest to wtedy mniej więcej
nie wlasnych, tylko kompilatora. chodzi glownie o skladnie,
zreszta duza czesc z tego jest w c99. kernel uzywa ich
dla zwiekszenia czytelnosci.
> takie C, jak rower pt. rower czterokołowy wyposażony w silnik
> z turbodoładowaniem (ustawodawca nijak nie chce zgodzić się,
> że to nadal rower... i nie trzeba prawa jazdy ;( !)
> I pozostaje kwestia co kto rozumie przez "moduł": jako
> "nieznacz" Linuxowego kernela wiem że istnieje w Linuxie
> pojęcie "moduł" oznaczające kawałek kodu robiący... nie wiem
> co: rzuć cytatatami, ja tylko popytam czy to może być:
> A. driver ?
owszem, wiekszosc zrodel w jadrze to wlasnie drivery.
> A1. driver wirtualny (np. obsługa filesystemu) - z drobnymi
> rozszerzeniami C się da (VMS: funkcje CMKRNL, CMEXEC itp)
asembler jest zbedny, musisz tylko pamietac o endianess
(do przeliczania tez sa odpowiednie funkcje, tzn. le_to_cpu()
itp). rozszerzen gnu nie musisz uzywac, aczkolwiek bywaja
przydatne z przyczyn podanych powyzej. a swoja droga, to
co w.w. funkcje robily w vms ? moj zwiazek z tym systemem
byl raczej luzny.
> A2. driver "fizyczny": jak np. wykonujesz *w czystym C*
> powrót przez IRET ? (zaznaczam: odpowiedź nie musi
> być trudna, np. system musi mieć w tym miejscu wsparcie
> obsługiwane jednak *poza* możliwościami C przez "B1" !)
mhm. iret cie nie interesuje - po prostu piszesz funkcje
obslugi przerwania, zwykly kawalek c, a potem wywolujesz
request_irq(numer, twoja_funkcja, SA_SHIRQ, "jakis device",
argument_do_twojej_funkcji);
takie rzeczy, jak iret cie nie interesuja, dla ciebie funkcja
konczy sie return; takie rzeczy, jak zapis czego trzeba do idt,
oraz wspomniany iret robi system. fizyczne grzebanie w sprzecie
to funkcje takie jak outb(); ewentualnei wsparte cli() itp
(zgadnij ktora co robi ;-), ktore sa w pelni przenosne,
tzn. sa zdefiniowane dla kazdej architektury (fakt, w asemblerze,
ale osobe piszaca driver raczej to nie interesuje ;-). masz tez
funkcje do pci, mapowania pamieci itd.
> B1. funkcja ingerująca w sterowanie driverami ? (tu IRETa
> nijak nie obejdziesz...)
sterowanie... chodzi ci o zmiane pewnych parametrow drivera
lub urzadzenia ? zaden problem, zwykle robi sie to przez
procfs, tzn. system plikow podmontowany przez proc, dzieki
czemu mozesz np. zrobic echo 100 > /proc/twoj_driver/parametr,
powedruje to przez vfs do procedury obslugi zapisu do tego
pliku udostepnionej przez twoj driver i zarejestrowanej przez
create_proc_entry(); i pare innych. bez asemblera. druga
metoda to obsluga ioctl(), tez bez asemblera rzecz jasna ;-)
> B2. obsługa funkcji specjalnych, np. debbugera ze wsparciem
> sprzętowym (ciekawe, jak z "czystego C" załadujesz rejestry
> specjalne...)
debugger... cos jak kbd ? fakt, tutaj trzeba juz uzyc
asemblera. aczkolwiek jest to dosc rzadkie zastosowanie.
generalnie modul do kernela to po prostu kawalek kodu ladowany
w przestrzen adresowa tegoz, co oznacza, ze moze robic cokolwiek,
na przyklad mozesz podmienic ktoras z funkcji sytemowych typu
open(). _bez_ asemblera i calkowicie przenosnie.
> Zaznaczam: podejrzewam iż nastąpiło nieporozumienie i jeden
> repondent miał na myśli "moduł, dowolny kawałek jądra obsługujący
> dowolną właściwość jądra, również taką że jej jeszcze nie ma
> i trzeba przepisać mapowanie pamięci, obsługę przerwań itp"
> a drugi "moduł, super-hyper-zipper wynalazek[1]" czyli
> zdefiniowane standardem rozszerzenie systemowe.
nie ma czegos takiego, jak zdefiniowane standardem rozszerzenie
systemowe. to, ze wiekszosc modulow korzysta z funkcji
udostepnionych przez kernel to inna sprawa. zreszta zaden
standard tego nie definiuje.
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 21:05:34 MET DST