On 3/11/2012 9:18 PM, Steven Dake wrote: > Ugh > On 03/10/2012 11:58 PM, Fabio M. Di Nitto wrote: >> > From: "Fabio M. Di Nitto" <fdinitto@xxxxxxxxxx> >> > >> > there are several reasons for this: >> > >> > 1) evs is only partially implemented with no plans to complete it >> > >> > typedef enum { >> > EVS_TYPE_UNORDERED, /* not implemented */ >> > EVS_TYPE_FIFO, /* same as agreed */ >> > EVS_TYPE_AGREED, >> > EVS_TYPE_SAFE /* not implemented */ >> > } evs_guarantee_t; >> > > We should implement safe at some point - its pretty easy to do. ok then please let´s readd stuff to the TODO list so we don´t miss it. > >> > 3) the only reason (I was told) to carry around evs was that evs >> > receives the full ring_id struct from totem. This is only >> > partially correct because while the structures are prepared >> > to carry around those data, they are never transmitted from >> > corosync engine down the IPC line to the user. >> > CPG ring_id contains the exact same information and it's >> > actually less buggy (due to prototying of the info). >> > > cpg has an entire membership layer - evs uses totem's built in > membership layer. That is the major difference. Yes but evs membership propagation from totem is broken. I am rather surprised nobody ever noticed. >> > worst case scenario where a user really absolutely need libevs, >> > it can be easily reimplemented as libcpg wrapper and avoid >> > lots of code duplication. >> > > I'd be open to a --enable-evs where evs was disabled by default.. > This i can probably live with. I´d still argue that if we need to keep 3K lines of code, it should at least be working ;) Fabio _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss