[Team2013] c constructor attribute

Ionut Nicu ionut.nicu at mindbit.ro
Fri Apr 12 14:41:01 EEST 2013


Buna,

On Fri, 2013-04-12 at 14:15 +0300, Andreea-Cristina Hodea wrote:
> 2013/4/12 Ionut Nicu <ionut.nicu at mindbit.ro>:
> > Ar trebui ca adaugarea vlan-urilor default sa se intample doar pe cazul
> > cand segmentul de shared memory nu exista deja (mm->init != 0).
> >
> > Daca tot modifici, cred ca ar fi bine sa scoti din shared_init()
> > initializarile protocol specific (pentru if_tags, cdp, rstp) si sa le
> > apelezi din sw_init().
> 
> Asta ar insemna sa mut si functiile shared_init_cdp, shared_init_rstp
> si cele referitoare la if_tags? Sau doar apelurile catre aceste
> functii sa se faca din sw_init? Iar if_tags sunt memorate ca o lista
> in structura de shared memory, lista care va trebui initializata
> totusi in shared_init?
> 

Am mai discutat putin cu Radu si sugestia noastra e ca shared.c sa fie
mutat in directorul switch si sa se numeasca switch.c. Oricum in
shared.c nu prea avem chestii generice. Partea generica de shared memory
este in lib/mm.c.

In acest caz shared_init() va deveni switch_init() (adnotat cu attribute
constructor) si aici poti sa faci toate initializarile (inclusiv crearea
de vlan-uri default) pe ramura in care mm->init != 0.

> > In shared_init() ar trebui sa se faca doar
> > mm_create() si pe cazul in care mm->init != 0 sa se faca doar memset-ul
> > cu 0.
> 
> In afara de memset cu 0, pot ramane in shared_init si initializarile
> listelor de descrieri, nu? Caci descrierile nu sunt specifice
> implementarii de backend.
> 
> > Cred ca solutia ar fi sa nu se mai creeze vlan-urile default din modulul
> > de kernel lisa. Astfel poti sa ai fix acceasi implementare de sw_init()
> > in userspace pentru toate back-endurile.
> >
> 
> Ok, deci scot cu totul sw_vdb_init din kernel?
> 

Nu totul, doar apelurile sw_vdb_add_vlan().


Ionut.



More information about the Team2013 mailing list