<div dir="ltr">Salut Ionut,<div><br></div><div style>Asa m-am gandit si eu si asa am implementat pana acum (inca nu am comis), dar cu o exceptie: sw_init nu primeste un pointer la switch_operations. Eu m-am gandit ca va accesa switch_operations prin, de exemplu, lisa_ctx.sw_ops.functie, unde lisa_ctx este initializat cu sintaxa de C99 in lisa.c si exportat prin lisa.h. Nu am un motiv bun pentru asta decat ca daca sw_init va fi constructor nu stiu cine ii va da ca argument sw_ops.</div>
<div style><br></div><div style>Pentru lisa, sw_init ar trebui sa faca chiar si mai putin decat vlan_add, fiindca exista sw_vdb_init in kernel. Astfel, sw_init trebuie sa faca doar shared_set_vlan_desc(vlan_uri_default, descrieri_default).</div>
<div style><br></div><div style>Zi faina,</div><div style>Andreea</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/4/12 Ionut Nicu <span dir="ltr"><<a href="mailto:ionut.nicu@mindbit.ro" target="_blank">ionut.nicu@mindbit.ro</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Buna Andreea,<br>
<br>
Cred ca ai dreptate. Ar trebui sa existe o functie de initializare a<br>
switch-ului sw_init (sau cum vreti voi sa o botezati) care sa fie comuna<br>
tuturor backend-urilor, pentru ca nu face nimic specific vreunui<br>
back-end. Prin "comuna tuturor backend-urilor" eu inteleg ca nu ar<br>
trebui sa fie membru in structura switch_operations.<br>
<br>
Functia asta ar tb sa fie adnotata cu attribute constructor si sa<br>
primeasca ca parametru un pointer catre switch_operations pentru a putea<br>
accesa metodele specifice back-endului curent pentru crearea de<br>
vlan-uri). Ar trebui sa apeleze shared_init() pentru crearea segmentului<br>
de memorie shared, apoi folosind pointer-ul la switch_operations sa<br>
creeze vlan-urile default.<br>
<br>
E ok pt voi abordarea asta?<br>
<br>
Ionut.<br>
<div><div class="h5"><br>
On Wed, 2013-04-10 at 20:10 +0300, Andreea-Cristina Hodea wrote:<br>
> Salut,<br>
><br>
><br>
> Cred ca pana la urma nu e ok sa adaugam vlan-urile default din<br>
> shared_init. Am scris de ce aici[1], asa ca as propune ca sw_api sa<br>
> aiba o functie init cu atributul constructor, fie ea sw_init, care<br>
> (poate printre altele) sa adauge vlan-urile default. In LiSA<br>
> Middleware asta ar insemna sa apeleze lisa_ctx.vlan_add pentru fiecare<br>
> vlan default.<br>
><br>
><br>
> Ceea ce nu stiu, insa, este ce se intampla daca o alta implementare a<br>
> API-ului omite sa implementeze sw_init? La incarcarea bibliotecii<br>
> dinamice primesc eroare sau raman cu vlan-urile default lipsa? Am mai<br>
> citit cate ceva despre acest atribut aici[2].<br>
><br>
><br>
> [1] <a href="https://github.com/lisa-project/lisa-user/issues/10" target="_blank">https://github.com/lisa-project/lisa-user/issues/10</a><br>
> [2] <a href="http://stackoverflow.com/questions/2053029/how-exactly-does-attribute-constructor-work" target="_blank">http://stackoverflow.com/questions/2053029/how-exactly-does-attribute-constructor-work</a><br>
><br>
><br>
> Andreea<br>
</div></div>> _______________________________________________<br>
> Team2013 mailing list<br>
> <a href="mailto:Team2013@lisa.mindbit.ro">Team2013@lisa.mindbit.ro</a><br>
> <a href="http://lisa.mindbit.ro/mailman/listinfo/team2013" target="_blank">http://lisa.mindbit.ro/mailman/listinfo/team2013</a><br>
<br>
<br>
_______________________________________________<br>
Team2013 mailing list<br>
<a href="mailto:Team2013@lisa.mindbit.ro">Team2013@lisa.mindbit.ro</a><br>
<a href="http://lisa.mindbit.ro/mailman/listinfo/team2013" target="_blank">http://lisa.mindbit.ro/mailman/listinfo/team2013</a><br>
</blockquote></div><br></div>