SVC_DELAY skupine 3

[GoogleCodeExporter]

Google je fejst! =D
Tu lahko v slovenščini, najbrž. Skupina 3, Gašper (kdo vse je pisal
svc_delay.s?), kostko, povejte mi, kako je sedaj s tem: kaj so user space
taski in kaj so sistemska programska oprema. Mimogrede, skupina 3, kaj je
vaš svc_delay? Kaj je potem svc_delay tukaj 
http://code.google.com/p/lbos-fri/source/browse/trunk/src/syscall.s? 
Kaj eden dela in drug očitno različno?

Mimogrede, napisal sem nek osnutni "coding standard", tukaj
http://code.google.com/p/lbos-fri/source/browse/trunk/CODING_STANDARD.txt

Hvala :)

Original issue reported on code.google.com by jernej.kernc@gmail.com on 29 Nov 2008 at 7:41

[GoogleCodeExporter]

Bom kar prilepil odgovor na Gašperjev mail, da razložim kaj je problem te 
commitane 
kode:

Fora je v tem da funkcija "register_timer" ubistvu naredi naslednje (podana sta 
mu 
dva parametra in sicer št. period - jiffies - zakasnitve in pointer na TCB 
procesa):

  * Zgenerira novo timer strukturo in jo vstavi na ustrezno mesto v 
prioritetni vrsti, glede na to koliko časa mora še preteči do prožitve 
timerja.

Vsako milisekundo pa se kliče prekinitveni handler "timer_irq_handler", ki 
naredi naslednje:

  * Ob prekinitvi se poveča jiffies counter, ki predstavlja število period 
od 
zagona sistema. Nato se preveri ali lahko sprožimo prvi timer v vrsti. V 
kolikor ga lahko, se zbudi prvi task in preveri ali lahko sprožimo tudi 
naslednjega (in tako naprej, ker so taski v sortirani prioritetni vrsti).

Torej "timers.s" že implementirajo možnost delaya več taskov (zato je tudi 
trenutna implementacija svc_delay tako kratka, ker je večina kode tam v 
timers.s). Torej ubistvu bi vi morali zamenjati tiste funkcije, ki so 
trenutno v timers.s (eno je registracija timerja, drugo pa prekinitvena 
rutina ki se proži na vsako milisekundo).

Original comment by kos...@gmail.com on 29 Nov 2008 at 11:06

[GoogleCodeExporter]

no, in zakaj bi to delali, če je že narejeno? :P

updateal sem wiki:README in TODO.

Voljno. :)

Original comment by jernej.kernc@gmail.com on 29 Nov 2008 at 12:37

[GoogleCodeExporter]

Sej mi lohk kr rasper pravte ;)

Ma ja, to nam je tkrt profesor povedal kako nej bi naredil rešitev za hkratno 
štetje
več delay-ev z enim timer-jem in mi smo pol tisto naredil, timer smo pa 
pogledal sam
tolk, kej prejema kot parametre, neč kej preveč podrobno, ker smo mislili, da 
je pač
navadn timer, ki ko prešteje vrednost samo postavi zastavco TWAIT na 0...tko 
da pol
smo vbistvu nardil nekaj podobnga kot je v timerju, samo na drugačen 
način...drugače
bi imel mi skoraj nič dela (samo posredovat podatke timerju in postavt 
zastavico
TWAIT), pa to je tud že itak napisan v trunk-u, tko da pol res ne vem, kako si 
je
profesor zamislu to...
V skupini smo pa: Gašper Rupnik, Anže Pečar, Tomaž Sečnik, Erik Hribar

Original comment by gasper.r...@gmail.com on 29 Nov 2008 at 2:34

[GoogleCodeExporter]

No, mi bi radi da bi se commital našo kodo tud v trunk - zadeva (delay) 
preverjeno
deluje -> trenutno so testni primeri narejeni tako, da lučke prižiga, ko task 
nekaj
dela in lučke ugaša, ko je task v 'delay-u' ... v končni verziji bo moralo to
delovati tako, da se bo na terminal izpisovalo, kaj določen task dela...mi tega
trenutno ne moremo še realizirat, ker skupina ki je zadolžena za to, to še ni
naredila -> ko bo, bo to trivialno popravit -> samo spremeniti kodo v tasku.
Sam sistemski klic pa deluje!

Spremenili smo kodo:
- 'syscall.s' // pri svc_delay smo dodali skok za našo kodo
- 'svc_delay.s'  // to smo dodali v naš projekt (koda za sistemski klic)
- 'timers.s'  // sprememba celotne kode
- dodali smo 4 taske v 'src/tasks'
- 'include/space.s' // dodali delaylist strukturo in vse potrebno za naše 
štiri taske
- 'include/structures.s' // dodali konstante
- 'include/globals.s' // dodali globalni spremenljivki CDLYTCB, DLYLIST in 
spremenili
MAXTASK
- in še v link file (config/layout.ind) smo dodali vse potrebno za naše 
štiri dodatne
taske.

To je več al manj vse (koda je v branches/group3)

LpG

Original comment by gasper.r...@gmail.com on 18 Dec 2008 at 10:17

[GoogleCodeExporter]

Nekaj komentarjev na strukturo kode:
 * Fino bi bilo, če bi bila koda v datoteki timers.s in ne v ločeni datoteki 
svc_delay.s

 * Prav tako bi bilo boljše, če se pri sistemskem klicu izognemo dodatnemu branchu, 
trenutno je namreč (vrstica 74):

   svc_delay:
     /* Jump to delay  */
     b dl_arfd

   Rešitev je seveda da se v tabelo sistemskih klicev doda neposredno dl_arfd.

 * Krajšanje imen (samo začetne črke besed) label velja samo za _notranje_ labele v 
funkcijah. Imena samih funkcij naj bodo raje nekaj v stilu 
timers_register/timers_unregister ipd.

 * V repozitorij ste commitali datoteke, ki niso potrebne za prevajanje kode in 
sicer so to naslednje:

   group3/project/lbos-fri.lbos-fri.elf.slo
   group3/project/Progress.log
   group3/project/sample.map
   group3/project/Debug [celoten imenik]
   group3/config/___Lnk.ind

   Te datoteke odstranite iz repozitorija.

Toliko na hitro z moje strani, vsebinski review kode pa še sledi.

Original comment by kos...@gmail.com on 18 Dec 2008 at 11:40

[GoogleCodeExporter]

Še nekaj glede strukture:
 * V svc_delay.s se v funkciji dl_arfd nahaja pogojni skok na labelo __dla_ovrflw, 
ki pa se nahaja spodaj pod funkcijo dl_drfd! Taka struktura dela zmedo.

 * Prav tako naj ima vsaka taka (notranja) labela jasen komentar kdaj se program 
lahko nahaja v tem odseku kode.

 * Lepo bi bilo da se spremenljivki DLYLIST/CDLYTCB premakne iz space.s v 
svc_delay.s (oz. timers.s glede na zgornji komentar). Spremenljivke naj gredo 
čisto 
na konec v svojo .data sekcijo (glej npr. vm.s)

Vsebinski komentar na kodo:
 * Koda odstrani globalni jiffies counter, ki šteje uptime sistema v številu 
milisekund. Trenutno se le-ta uporablja zgolj za realizacijo timerjev, vendar 
je 
vrednost uporabna tudi drugje, tako da naj se obdrži.

 * Alociran prostor za DLYLIST je 80 bajtov. Iz kje sledi ta številka in kako nanjo 
vpliva večanje št. taskov ? Glede na to da lahko vsak task registrira zgolj 
en 
timer naenkrat naj se uporabi vrednost, izračunana glede na število taskov v 
sistemu. V primeru dinamične alokacije taskov, bo potrebno dinamično 
alocirati tudi 
deskriptorje timerjev.

 * DLYLIST zgleda kot polje in ne povezan seznam. To je težava, ker tako polje ni 
preprosto dinamično spremenljivo. To se lepo vidi, ko je potrebno npr. dodati 
nek 
element v sredino - zamik vseh vrednosti je potraten! Poleg tega bo tako polje 
predstavljalo problem, ko bo mogoča dinamično kreiranje taskov med delovanjem 
sistema.

 * Zakaj je potrebna spremenljivka CDLYTCB ? Ali ni mogoče trenutnega TCBja 
razbrati neposredno iz seznama registriranih timerjev ?

Zaenkrat to.

Original comment by kos...@gmail.com on 18 Dec 2008 at 12:15

[GoogleCodeExporter]

* to glede strukture kode bomo popravili v kratkem, prav tako odstranili 
nepotrebne
datoteke, ki niso potrebne za prevajanje kode.

* DLYLIST je velik 80 bajtov, ker je profesor na začetku zadal nalogo tako, da 
naj bo
to tabela fiksne dolžine (za 10 procesov ker več jih ne bo za testiranje) -> 
zato smo
se potem mi tako lotili nalogo, da smo DLYLIST ustvarili kot polje in dodali 
samo
izhod v primeru overflow-a tabele, drugače bi seveda uporabili povezan seznam, 
vendar
je povedal, da ni potrebno komplicirati.

CDLYTCB uporablja zato, ker so v tabeli shranjeni sami procesi, ki še čakajo 
na delay
-> tisti, ki pa je trenutno v štetju ga tako ni več, to pa zato, ker lahko 
vmes pride
zahteva za nov delay in bi zato tabelo DLYLIST premešalo skupaj s tem, ki je 
trenutno
že v štetju -> zato se ga prej odstrani.

LpG

Original comment by gasper.r...@gmail.com on 18 Dec 2008 at 12:48

[GoogleCodeExporter]

1. Kar se tiče DLYLIST bo izvedba s poljem problem pri implementaciji 
dinamičnih 
taskov, prav tako pa vidim da je že problem pri odstranjevanju elementa - kako 
namreč odstranite element iz polja ? Zamaknete vse elemente v levo (kar je 
potratno) ? Če bi uporabili povezan seznam, bi bila rešitev veliko bolj 
enostavna. 

Skratka vaša rešitev ne omogoča enostavne uporabe kode v primeru, ko bomo 
potrebovali dinamično resizable tabelo timer deskriptorjev (trenutna 
implementacija 
v trunku uporablja povezan seznam, kjer bi bilo preprosto dodati dinamično 
alokacijo, ko bo le-ta na voljo).

2. Ko se izvede TC0 IRQ preverite kateri timer je naslednji v vrsti za 
izvajanje 
(to je vedno prvi). Kje bi lahko tukaj prišlo do zahteve za nov delay 
(prekinitve 
so tukaj onemogočene, ker smo v prekinitveni rutini) ?

Original comment by kos...@gmail.com on 18 Dec 2008 at 1:34

[GoogleCodeExporter]

Ni problema, to glede izvedbe DLYLIST-a preuredim čez praznike, najbrž ni 
prof.
Mahkovič predvidel, da bo prišlo tako daleč s projektom.

Tisti čas, ko je en v štetju (ko čaka na TC0 IRQ) so omogočene prekinitve 
in lahko
pride nova zahteva in se postavi v DLYLIST.

Ok, ko popravim to se slišimo

LpG

Original comment by gasper.r...@gmail.com on 18 Dec 2008 at 6:03

[GoogleCodeExporter]

no, pa da še jaz dodam svoje kratko irelevantno mnenje:
*asistent* dr. *Mahkovec* ni avtoriteta pri tem projektu,
neuradno odkar stoji /p/lbos-fri in podaljšan TODO (in poguba LBOS.pdf, sori),
uradno pa od Kosovega predavanja prejšnji teden.

Izključna avtoriteta po znanju, volji in ne po dolžnosti je, kot, vidim, si 
že
sprejel, on, zato vprašaš in se posvetuješ z njim.
To je dobro in od njega se lahko jaz in ti, in vsi ostali pri vas, kdor dela, le
naučimo. In vsi ostali iz vseh drugih skupin. ;)

ja, in zdaj ta svc_delay...
a mi lahko prosim razložiš, kaj vaš svc_delay.s v osnovi dela drugače kot 
bivši timers.s?
sicer, če popravljate/dopolnjujete/izboljšujete timers.s, lahko pišete kar 
vanj
(popravite/dopolnite/izboljšate).
in če popravljate statično polje v dinamičen povezan seznam,
definirajte strukture (elemente seznama, primer oz. je že na pol definirano
http://code.google.com/p/lbos-fri/source/browse/branches/group8-perice/include/s
tructures.s#33

in naprej imaš še dva "REQUEST DESCRIPTOR") in za dodajanje elementov v seznam
uporabite dinamično alokacijo (sedaj funkcijo mm_alloc_page (in mm_free_page ob
brisanju), kmalu pa se bo ta nadomestila z kmalloc, ki bo bolj fin).

če sem prav razumel, gre za povezan seznam, urejen po 'number of jiffies'?

hvala za razumevanje :)

Original comment by jernej.kernc@gmail.com on 18 Dec 2008 at 7:23

• Changed state: Started

[GoogleCodeExporter]

Ja, gre za povezan seznam, urejen po 'number of jiffies', kjer nek i-ti element
tabele v resnici predstavlja vsoto vseh pred njim v tabeli + samega sebe.
Bolj podrobno je napisano tu 
->http://code.google.com/p/lbos-fri/wiki/planOfDelay

Na kratko...razlika je v tem, da je bivši timers.s uporabljal tak način za 
štetje, da
je gledal na cur_jiffies (čas v ms od zagona sistema) in potem se po njem 
orientiral
in brisal T_WAIT zastavice procesom. Ta pa deluje tako, da se postavijo v seznam
zahteve za delay tako, kot sem ga prej gor opisoval (in je na wiki-ju 
predstavljen)
in potem postavi za štetje cifro, ki je v prvem elementu seznama...ko to 
prešteje
briše zastavico T_WAIT prvega in vzame cifro drugega elementa seznama...itd.

To glede asistenta mi pa ni več jasno zdj kako...namreč takrat, ko smo se 
nazadje tu
gor menil sem mu potem povedal, da je svc_delay na lbos-fri že narejen, sicer 
malo
drugače...sam pa je odgovoril da on bo ocenjeval naš svc_delay, kot smo ga 
dorekli ->
tko da zdj bi res rad zvedel kako je zdj s tem projektom? Da nbomo potem naša 
skupina
ostala brez ocen zaradi nesporazuma z asistentom. 

Meni seveda ni problem popravit statično polje v dinamičen povezan seznam (to 
najbrž
nebi bil prevelik odmik od tistega kar pričakuje asistent od nas...in je 
seveda tudi
dosti boljši), samo če bo pa delay implementiran čisto drugače kot smo se 
na začetku
semestra z njim dogovorili (ko se je vsaka skupina hodila menit gor k njemu) je 
pa
takrat reku, da ga nebo upošteval, kot da je naš...

Original comment by gasper.r...@gmail.com on 18 Dec 2008 at 7:50

[GoogleCodeExporter]

A lahko prosim brez nepotrebnega politiziranja tlele na bugtrackerju in da se 
osredotočimo izključno na tehnično plat reviewja kode v group 3 branchu.

Hvala.

---

Torej kar se tiče zamenjave polja s povezanim seznamom je le-ta nujna za merge 
v 
trunk saj tam to rabimo zaradi prihajajočih dinamičnih taskov. Zanima me še 
naslednja zadeva kar se tiče kode:

 * Če prav vidim ste spremenili mersko enoto - 1 jiffie ni več ~ 1 ms, temveč ~ 
0.25 ms ?

 * Vrednost zakasnitve posredujete neposredno timerju - to omeji maksimalno 
zakasnitev na okoli 1 sekundo (register TC0_RC je zgolj 16 biten, maksimalna 
vrednost 0xFFFF pa je zgolj ~ 1008 ms). To je nekam omejujoče ? Ravno zaradi 
tega 
trenutna implementacija v trunku uporablja ločen jiffies števec, ki je lahko 
poljubno biten (trenutno je 32 biten, brez težav pa bi se lahko uporabljal 
tudi 64 
biten števec).

Če sem kaj spregledal me kar popravi :)

Original comment by kos...@gmail.com on 18 Dec 2008 at 8:27

[GoogleCodeExporter]

glej, jaz tvojega ne bom ocenjeval, zato me toliko ne jemlji za ziher.
vprašanje tudi, če bo tvoje ocenjeval mahkovec oz. če to dela, in sem se jaz 
danes z
njim pogovarjal, potem bo groza :&

no, anyway, poskrbimo, da bo to kar boste oddali kar najboljše, če preseže 
začetno
omejene zastavke, ne bo niti mahkovec nič jezen. se bomo tudi glede ocen na 
koncu
skupaj zmenili :P

ampak še vedno pa mi ni jasen svc_delay. sori :>
kaj ti pravzaprav ni všeč pri izvedbi sedanjega timers.s, razen da ni urejen
dinamičen seznam? sedaj dela tako, da ko proces zahteva delay, se pogleda kok 
je
trenutni jiffies (ki, btw, kaže uptime (---kako bomo naredili uro?)) in se mu
prišteje željeni delay in se vpiše aktiven timer. proces tako spi, dokler ga
timer_irq_handler ne zbudi, ko trenutni jiffies doseže shranjeni. kaj je tu 
narobe?

ali delay delate izključno zato, ker ste se tako davnega zmenili s mahkovcem? 
(to ni
dobro)
v tem primeru lahko imate. jaz ne bom commital v trunk. :)

P.S: sori, res mi ni jasno, gledam tudi (nekonsistenten?) primer na planOfDelay 
in ne
razumem. kakšen je namen? kakšni potrebi zadošča?

to mi tudi ni jasno
"in potem postavi za štetje cifro, ki je v prvem elementu seznama...ko to 
prešteje
briše zastavico T_WAIT prvega in vzame cifro drugega elementa seznama...itd."
in kaj pomeni to
"Thus we have achieved more counting delays by one timer."
?
sej timer je samo en?

še enkrat se opravičujem, da ne boš mislu, da se kej zajebavam :P
res mi ni jasno in res me zanima.

hvala 

Original comment by jernej.kernc@gmail.com on 18 Dec 2008 at 8:35

[GoogleCodeExporter]

vse on topic :)

Original comment by jernej.kernc@gmail.com on 18 Dec 2008 at 8:39

[GoogleCodeExporter]

@kernc:
Ja ne, sej ni nič narobe s sedanjim timers.s v trunku in tud kot vidim se ta 
delay
dela na tak način izključno samo zato, ker je tako določil asistent, kar vem 
da ni
dobro...sam kej nej potem jest proti asistentu? Pa tudi ne vidim boljše 
rešitve kot
to, ki je že v trunku...samo kaj naj potem pa mi naredimo?

Recimo da imaš tri procese, ki zahtevajo delay:
1.. 80ms
2.. 100ms
3.. 150ms

Koda jih postavi v strukturo tako:
|80|20|50
In nato da prešteti prvi element tabele (80ms). Ko tega prešteje je tako 
preštetih
80ms vseh treh procesov (1.,2. in 3.)

Tabela postane sedaj:
20|50
Iz nje se vidi, da je ostalo še 20ms za 2. proces in 50ms za 3. proces. Tako 
da sedaj
preštet spet prvi element tabele (20ms), ki predstavlja 20ms od 2. in 3. 
procesa.

Sedaj ostane še:
50
Kar pomeni, da ostane za preštet še 50ms za 3. proces.

Skratka, ni navadna tabela urejena po velikosti, ker drugače bi bila naslednja:
80|100|150
In bi se najprej štelo 80ms za 1. proces, nato 100ms za drugi proces in na 
konc še
150ms za tretji proces -> torej bilo bi zaporedno štetje in ne vzporedno kot 
je pa v
našem primeru (s tem je mišljeno štetje delay-ev več procesom hkrati).

@kostko:
mersko enota je manjša zaradi potrate časa že v sami kodi -> vsekakor nujno
spremeniti v seznam.

Original comment by gasper.r...@gmail.com on 18 Dec 2008 at 9:13

[GoogleCodeExporter]

@gasper:
Ja povezan seznam bi moral izboljšati performanse, saj ne bo treba več 
kopirat 
stvari sem ter tja ob brisanju elementa. Kaj pa tisto glede maksimalne 
zakasnitve ? 
Tisto res velja ali sem kaj zgrešil ?

Original comment by kos...@gmail.com on 18 Dec 2008 at 9:41

[GoogleCodeExporter]

Ja, stvar sem preveril TC0_RC sprejme max zgolj samo 0xFFFF, torej bi blo treba 
za
večje zakasnitve to realizirat nekako drugače...samo potem je že vprašanje, 
kolk je
potem sploh še smiseln ta naš način realizacije?...ker če pogledam vse 
skupaj, bo na
konc ta v trunk-u dosti enostavnejši...:-/

Original comment by gasper.r...@gmail.com on 18 Dec 2008 at 10:43

[GoogleCodeExporter]

rasper, hvala! končno se mi je posvetilo. :)
svc_delay v bistvu "računa" neke razlike med delayi, kar pa je, kot smo 
ugotovili,
povsem nepotrebno, saj ima lahko vsak task svoj "realni" in se izloči natanko 
predvideno.
in pri
80|100|150
se najprej 79 ms ne zgodi nič, nato se starta prvi in nato čez 20 ms drugi 
... kot se
*že* dogaja sedaj.

torej, kar se mene tiče, lahko bivši timers.s za začetek popravite tako, da 
bo
namesto v pool, shranjeval v *urejen seznam* ("navodila" v [c10]). tako bo
timer_irq_handler najhitreje vedel, ali je sploh delay in kateri.

potem pa bomo še kaj našli.

gut? :-)

Original comment by jernej.kernc@gmail.com on 19 Dec 2008 at 7:49

[GoogleCodeExporter]

Nekako se mi zdi, da bi lahko bila kombinacija obeh načinov (ta, ki je 
trenutno v
trunk-u in ta naš način) bil kar hiter, če bi ohranil ta način shranjevanja 
(kjer se
računa razlike med delay-i), samo da bi se shranjevalo v seznam in ne 
tabelo...s
kombinacijo cur_jiffies načina, ki je trenutno v trunku...bom probal nekaj
poeksperimentirat, pa se bo pol na koncu vidlo, kako se obnese ta način oz. 
kako je
hiter...sej to je itak glavno, da se dobi najboljšo rešitev, potem pa lahko 
asistent
reče kar hoče :-P

LpG

Original comment by gasper.r...@gmail.com on 19 Dec 2008 at 10:08

[GoogleCodeExporter]

Točno tako, najboljša koda vedno zmaga :)

Original comment by kos...@gmail.com on 19 Dec 2008 at 11:53

[GoogleCodeExporter]

Dodana je nova koda za svc_delay...upošteval sem vse nasvete:)...sedaj se koda 
nahaja
samo v timers.s
Kodo moram še v praksi stestirat (sedaj stestirana samo na papirju:) )...kot 
sem
gledal z zdajšnjim timers.s v trunku, se razlikuje register_timer v tem, da ma 
malo
manjša KO ter par ukazov manj...kera koda od teh dveh se pa še v praksi 
hitreje
obnaša moram pa še stestirat.

LpG

Original comment by gasper.r...@gmail.com on 7 Jan 2009 at 3:41

[GoogleCodeExporter]

sedaj tudi stestirana.

Original comment by gasper.r...@gmail.com on 8 Jan 2009 at 11:18