Hali!

Adva van egy router 3 darab halokartyaval.  Ha az egyiken 
bejon egy csomag, az bele van routolva a masik fizikai 
interface-n ulo tunnel driverba.  Namarmost, azt szeretnem, 
hogy bizonyos esetekben a csomag egy masolata, alkalmas modon 
becsomagolva, kimenjen a harmadik halokartyan.  Ez az 
alkalmas eset ez fugg az skb->tc_index -tol, & a tunnel 
driverben beallitott informacioktol.

A problema ott kezdodik, hogy ha barmilyen kicsit 
osszetettebb dolgot probalok megcsinalni a a tunnel driver 
hard_start_xmit -jebol (akar csak egy __dev_get_by_name -t 
is), a kernel rogton panikol.

Valami otlet, hogy hogyan lehet ezt megoldani?  (Vagy hol 
lehet megkerdezni valakit akinek lehet otlete?)

Koszi

ImRe

On Sat, 9 Mar 2002, Torok & Rucz wrote:

> > Egy (brutalis) megoldas: mindegyik ilyen objektumodhoz (tank, stb.)
> > tartozzon egy kulon thread, ez frissitheti a grafikat, mozgathatja magat
> > az egyseget, stb. A user inputot egy kulon thread-ben (mondjuk magaban a
> > foprogramban) kezeld. Amikor inputot kell atadni az objektumnak (pl. a
> > tank celpontot kapott), akkor az inputkezelo thread meghivja a tank
> Ertem, de hogyan oldjam meg azt a problemat, hogy a bementeti esemenyeket
> minden -arra potencialisan reagalni kivano- objektum megkapja, uzenetszeruen,
> tehat, ne kelljen neki allandoan figyelnie.

Amikor jon az esemeny, akkor egyszeruen meghivod pl. a tank objektum
esemenykezelo metodusat. Ez masik thread-ben fog futni, mint a tank
objektum "fo thread"-je, de beallithatja az objektum egy valtozojat, es
ezt a tank "fo thread"-je eszreveheti kesobb.

> A masik pedig az a gond, hogy a
> framebufferhez nem szabad egyszerre hozzaferni ket kulon szalbol, illetve
> az is gond, hogy az adott objektum, nem biztos hogy tudja, hogy a kepernyon
> epp latszik-e, nem beszelve arrol, hogy tegyuk fol parhuzamosan irnak a
> gr. membe, kozben meg mondjuk gorgetem a kepernyot, szoval valtozik a
> kornyezet.

Akkor valoszinuleg az a celszeru megoldas, hogy csak egy thread rajzol.
Ez tudja, hogy melyik objektum latszodik a kepernyon es csak azokat
rajzolja ki.

> > Szinten a fenti programomban azt kovettem el, hogy a foprogram
> > osztalyaban volt egy statikus objektum, ami tartalmazta az osszes
> > kirajzolando elemet.
>
> Ez nem egeszen vilagos, mi az hogy a foprogram osztalyaban volt egy statikus
> objektum?

Java-ban nem lehet kulon fuggvenyt csinalni, a main-nek is egy osztaly
metodusanak kell lennie.

> > kozul azt, amelyiknek a teruleten volt a klikkeles, aztan szoltam az
> > objektumnak, hogy most o ki van valasztva es rajzolja magat ujra. Amikor
> > pedig tudja magarol az osztaly, hogy ki van valasztva, akkor rajzol maga
> > kore egy keretet. Biztos van elegansabb megoldas, ez egyszeru volt.
>
> Hmm, es ha egy masikat jelolsz ki?

Nyilvantartottam, hogy melyik objektum van eppen kijelolve.

> Hogyan tudja meg hogy mar nincs kijelolve,
> illetve nem okozott gondot, hogy mikozben a kerdeses objektum fut egy
> szalban, addig te az egyik (virtualis) fuggvenyet hivogatod, illetve
> adatait modositod?

_Ez_ az, ami problemat okozhat :-) Azert kell szemaforral vedeni azokat
a valozokat, amelyeket tobb thread-bol is irhatsz/olvashatsz.

[...]
> > szemaforok (mutex-nek hivja oket). Valahogy igy kell hasznalni oket:
> Ennek kicsit utana jartam, meg mindig nem vagyok pontosan tisztaban a
> hasznalatukkal, de a szemafor es a mutex ket kulonbozo dolog nem?

Most elbizonytalanodtam. Picit utananezten en is, es ugy nez ki, a mutex
annyiban kulonbozik, hogy elmeletileg a mutex-et csak az a thread
engedheti el, amelyik lefoglalta, a szemafort meg nem. Hiaba, regen
tanultam mar ezt :-)

> > void setKiVagyJelolve(bool b) {
> >   pthread_mutex_lock(&jelol_szemafor);
> >   kiVagyJelolve=b;
> >   pthread_mutex_unlock(&jelol_szemafor);
> > }
> > void kirajzol() {
> >  ...
> >  pthread_mutex_lock(&jelol_szemafor);
> >  if (kiVagyJelolve) rajzolKeret();
> >  pthread_mutex_unlock(&jelol_szemafor);
> > }
>
> Ezt most nem egeszen ertem, mit reprezental a KiVagyJelolve es mit a
> jelol_szemafor?

Ez a kettot ugy kepzelem, hogy pl. a tank osztalynak van ez a ket
metodusa. A kiVagyJelolve valtozo az osztaly member valtozoja. A
setKivagyJelolve() metodust az esemenylekezelo thread hivhatja, a
kirajzol() metodust pedig a kepet frissito thread. Mivel mindket metodus
hasznalja a kiVagyJelolve valtozot es kulon thread-ekbol hivjak meg a
metodusokat, ezert meg kell vedeni a jelol_szemafor-ra (illetve
mutex-szel), nehogy egyszerre nyuljanak hozza.

				Bye,NAR
-- 
"Beware of bugs in the above code; I have only proved it correct, not
 tried it."