[Team2013] c constructor attribute

[Andreea-Cristina Hodea]

2013/4/12 Ionut Nicu <ionut.nicu at mindbit.ro>:
> On Fri, 2013-04-12 at 14:15 +0300, Andreea-Cristina Hodea wrote:
> 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.
>
>> Ok, deci scot cu totul sw_vdb_init din kernel?
>>
>
> Nu totul, doar apelurile sw_vdb_add_vlan().

Acum sunt un pic derutata. Daca mut shared.* in switch/switch.*, toate
tool-urile din userspace care includ acum shared.h vor include de acum
switch.h; am inteles corect? Din cate am observat, daca o functie are
atributul construct, chiar daca doar includ header-ul, acea functie
este apelata. Daca switch_init() va fi constructor, vad 2 consecinte:
1. oricine include switch.h nu va mai chema switch_init()
2. implementarile pentru sw_api fie nu vor mai avea constructor pentru
adaugarea vlan-urilor default si descrierile vor fi adaugate in
switch_init (care este constructor, iar adaugarea vlan-urilor pe bune
va ramane in sw_vdb_init, in kernel), fie vom avea totusi un
constructor per implementare care va apela ceva similar cu
lisa_ctx.sw_ops.vlan_add per vlan default.

Eu as opta pentru varianta a doua, cu un constructor
generic(switch_init) si unul specific(backend_init).

Andreea