Reviewed-by: Steven Dake <sdake@xxxxxxxxxx>
On 03/11/2012 01:28 PM, Fabio M. Di Nitto wrote:
> 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
