Odakle poceti? (kernel programming na Linuxu)

Pod pretpostavkom (tacnom ) da se u Linux razumem kao Marica u... Linux
Dakle, dodir sa Linuxom mi je bio na "home use" nivou, sem "pokreni Linux install" i instalacije Firefoxa, bukvalno nista ozbiljnije nisam radio.

Ali trebaci mi da ukljucim i kernel programming u linuxu uskoro, pa koja je distribucija najzgodnija za to i koji DevEnv da koristim?

Uf, teska tema

Ja sam se ovime bavio na fakultetu tako da je moje znanje limitirano ali probacu da napisem nesto korisno.

Preduslov za kernel programming je da znas dobro C i da imas teoretsko znanje o Linux kernelu, Linuxu i hardware-u (CPU, Memorija, kesiranje...). Nije realno da znas sve detalje ali neko uopsteno znanje je vise nego pozeljno. Distro koji sam koristio je bio Ubuntu jer sam kasnije radio i razvoj Android OS-a pa mi je bilo zgodno jer Google njega preporucuje, ali mislim da mozes da koristis bilo koji. IDE mi je bio obican tekst editor ali potrazi na netu, sigurno postoje neki koji moze da se koristi. Source code mozes da nadjes na kernel.org. Na pocetku samo raspakuj arhivu i prouci organizaciju (ima tekstova na netu o tome). Posle probaj da kompajliras i instaliras kernel. Tu ima finta da radis paralelno kompajliranje, da se ukljuci kesiranje... Najbolje je da se igras

Kada to naucis i savladas, probaj da malo izmenis kernel, npr. dodaj neki sistemski poziv koji ce da stampa nesto. Posle dodaj sistemski poziv koji npr, cita sve procese koji je pokrenuo user sa odredjenim ID-om i vraca to u user space. Nauci sta su moduli, napravi neki. Prouci strukture podataka koje dolaze uz kernel (lancana lista ima veoma interesantnu implementaciju). Prouci kakav se code style i organizacija koda ocekuje.

Najbolja dokumentacija koju sam nasao je sam source code ali ima dosta clanaka na ovu temu. Ovo su neki od sajtova koje sam koristio.

http://www.tldp.org/LDP/tlk/tlk-toc.html
https://www.win.tue.nl/~aeb/linux/lk/lk.html#toc10
https://kernelnewbies.org/Documents
https://www.kernel.org/doc/html/latest/

Mislim da ce Kernel.org biti najbolji za pocetak.

Radio sam vec drivere za Windows, tako da se razumem u osnove (i C i assembler ), rad hardvera (storage i nesto network, ostalo slabo bas).

Thanks, proucicu cim vreme dozvoli

alfaunits je napisao(la):

Mislim da ce Kernel.org biti najbolji za pocetak.

Radio sam vec drivere za Windows, tako da se razumem u osnove (i C i assembler ), rad hardvera (storage i nesto network, ostalo slabo bas).

Thanks, proucicu cim vreme dozvoli

Kliknite za proširenje...

Na ovom forumu neces naci to sto trazis.

Obzirom da si lako uvredljiv avantura ce biti kratkog daha, dok tvoj kod ne vide Linusove oci

Sala mala. Da pravim taj izbor poceo bi sa Debianom. Linux je jos uvek low level tako da editor po zelji a mislim da pozivanje na neku C biblioteku u razvoju nije opcija iz vise razloga. Glibc je namenjen razvoju korisnickih aplikacija. Mene vise zanima userland jer je Linux ekosistem tu tanak a realno nemam znanja za razvoj kernela. Sto se tice pozivanja na C lib:

System libraries (such as glibc, libreadline, libproplist, whatever) that are typically available to userspace programmers are unavailable to kernel programmers. When a process is being loaded the loader will automatically load any dependent libraries into the address space of the process. None of this mechanism is available to kernel programmers: forget about ISO C libraries, the only things available is what is already implemented (and exported) in the kernel and what you can implement yourself.

Note that it is possible to "convert" libraries to work in the kernel; however, they won't fit well, the process is tedious and error-prone, and there might be significant problems with stack handling (the kernel is limited to a small amount of stack space, while userspace programs don't have this limitation) causing random memory corruption.

Many of the commonly requested functions have already been implemented in the kernel, sometimes in "lightweight" versions that aren't as featureful as their userland counterparts. Be sure to grep the headers for any functions you might be able to use before writing your own version from scratch. Some of the most commonly used ones are in include/linux/string.h.

Whenever you feel you need a library function, you should consider your design, and ask yourself if you could move some or all the code into user-space instead.

Kliknite za proširenje...

https://kernelnewbies.org/FAQ/LibraryFunctionsInKernel

String processing i sinhronizacija sigurno postoji, osnova je svega moguceg. Dalje od toga su mi nebitne libs.

Zavisi sta treba da dodaš u kernel. Ja sam se bavio backportom elo touchscreen drivera u stariji kernel. Treba da razumeš device tree i da vidiš gde tvoj driver treba da bude. Analizom nekog od postojećih drivera možeš mnogo da naučiš.

Sent from my Pixel 2 XL using Tapatalk

Najbolje je da kreneš od neke embedded platforme kao što je Beaglebone i da integrišeš drajvere za razne periferije koje mogu da se dokupe. Fokusiraj se na određeni podsistem jer je kernel gomila apstrakcionih slojeva, pa nije isto pisati drajver za npr. temperaturni senzor na I2C gde vrtiš petlju koja čita sa magistrale i na upit ispisuje u /dev fajl, i npr. pisati storage drajver. Drugo, kernel development može da znači dve stvari: pisanje drajvera (prostije) i menjanje mehanizama samog kernela (alokator, baferovanje, scheduler itd). Ti bi verovatno radio ovo prvo. Vodi računa da, kao što su rekli, gomila C bibliotečnih funkcija ne postoji na nivou kernela ili radi drugačije, jer neke stvari "dole" prosto nemaju smisla (npr. otvaranje fajla na disku, jer fajl je apstrakcija a u trenutku kad se tvoj drajver podiže, možda nijedan storage nije ni montiran).

Imam solidno iskustva u ovome (doduše mahom pre nego što je device tree postao standard, najviše na generaciji 2.6 za razne Texas Instrumentsove procesore i 3.0 za i.MX6), pisao sam i neke svoje drajvere. Nemam da preporučim neke knjige jer su sve mahom zastarele pošto se kernel prebrzo razvija i menja, ali dosta dokumentacije imaš u stablu kernel source-a (folder Documentation). Fokusiraj se na sledeće teme:

1. Šta je kernel modul i kako se piše (kreni od nekog postojećeg uređaja iz kategorije uređaja koje te interesuju)
2. Šta je memorijski mapirani I/O, kako se prilazi registrima uređaja koji su mapirani na memorijske adrese procesora, i kako se koristi funkcija ioremap()
3. Kako se osobine uređaja opisane u device tree tabeli očitavaju iz samog drajvera
4. Kako se registruju i pišu interapt hendleri (request_irq / free_irq)
5. Kako se pišu polling petlje u drajveru tako što funkcija sama sebe zakaže za ponavljanje (schedule_work / schedule_delayed_work)
6. Kako se podaci propagiraju do user space-a i kako aplikacije mogu da šalju podatke drajveru (create_proc_entry za /proc/*, mknod za /dev/*)

U svakom slučaju, radi se o odvratnom i nezahvalnom poslu i osim ako ne planiraš to da radiš čisto iz hobija i osposobljavanja manjih embedded uređaja (gde nije kritično da drajver funkcioniše tip-top), onda bar gledaj da za to budeš dobro plaćen

yooyo je napisao(la):

Zavisi sta treba da dodaš u kernel. Ja sam se bavio backportom elo touchscreen drivera u stariji kernel. Treba da razumeš device tree i da vidiš gde tvoj driver treba da bude. Analizom nekog od postojećih drivera možeš mnogo da naučiš.

Kliknite za proširenje...

Ima li nekih na kernel.org ili su nezavisni?
Mene zanimaju "softverski" driveri (file system, FS filtering). Barem za sada nisam zainteresovan da kontrolisem konkretan hardver (FS ne kontrolise hardver, vec volume, a volume manager dalje hardver preko storage managera )