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
