On 04/13/2012 02:47 AM, Fabio M. Di Nitto wrote:
> On 4/13/2012 11:07 AM, Jan Friesse wrote:
>> I invite all of our contributors to help define the X.Y roadmap of
>> Corosync. Please submit your ideas on this list. Some
>> examples of suggested ideas have been things like "remove binding to
>> localhost", "don't rely on multicast loop facility" or "include user
>> data in cpg join/callbacks".
>>
>> Please submit your ideas by May 11, 2012 (Friday).
>
> - re-evaluate using libtool to link libraries.
> current method is suboptimal and it´s not easy to port across
> different OS´es.
>
> - reorganize library/headers/code in the tree.
> right now we have libraries in 3 dirs:
> common/ (corosync_common)
> exec/ (totem)
> lib/ (user exposed service libraries)
>
> the logical division is crystal clear but it has the disadvantage
> to duplicate a lot of the build logic around and it duplicates
> some util.h bits (confusing).
> It also make header inclusion a bit more complex than it needs to be.
> Also the way headers are layered it creates an unnecessary amount
> of define/struct duplications between user visible header/ipc/services
>
this seems like a major change - not something suitable for a y release
but perhaps an x release.
> My suggestion is to simplify it all at once (only because it makes
> more sense to do it in one-pass) by:
>
> 1) move all the libraries in libs/ subdirectory and still retain
> logical division libs/{common,totem,lib}
> 2) move all internal headers to includes/internal
> 3) deduplicate definitions by creating corosync/common/ headers
> to share between exec and user libraries.
>
> *NONE* of the above has any user visible change (except for
> packagers).
>
> the end result would be cleaner in terms of code location,
> headers readability (this needs to be discussed in more details)
> and deduplicating data around.
>
> One simple example to make it more clear (that applies to some
> structs and many other defines too in several services):
>
> [fabbione@daikengo corosync]$ grep VOTEQUORUM_INFO_LEAVE * -r | grep
> define
> include/corosync/ipc_votequorum.h:#define VOTEQUORUM_INFO_LEAVE_REMOVE
> 32
> include/corosync/votequorum.h:#define VOTEQUORUM_INFO_LEAVE_REMOVE
> 32
>
> There is no point to keep this duplication around.
>
> votequorum.h can simply include common/votequorum.h
> ipc_votequorum.h can do exactly the same
>
yes
> common/votequorum.h would define INFO_LEAVE.
>
> From a votequorum (or service foo) perspective there are no changes
> as the application using it will see no difference, but it simplifies
> the amount of code changes when adding new flags or adding new IPC
> calls and all.
>
> - change and simplify build defaults.
> Right now we have a major discrepancy between the way we build
> upstream and the way distributions build corosync.
> Default corosync is to build no features unless enabled.
> Default for distributions is to build everything that can possibly
> be built.
> I think this is just plain silly.
The reason is we don't want to have a ton of build/runtime dependencies
by default. The current system makes perfect sense. If a distro wants
to go to the trouble of enabling all of those things, then they can sort
it out. Asking them to "trim" makes less sense - how will they know
what to trim?
> My suggestion here is:
> - architecture independent features should be on by default
> (example: xml, dbus, monitoring, watchdog, augeas, systemd,
> initddir...)
systemd, dbus, watchdog, augeas are all either platform or linux
specific so they are not candidates for enable by default.
> - architecture dependent features should be off by default
> (example: rdma, small-footprint)
> - general policy for features:
> - stable feature: ON
> - devel/experimental features: OFF
This is how the code base builds currently.. Everything is fairly
experimental that isn't already in an on state.
> - test/debugging components/options off by default
>
> In time we can take a step forward and remove all the conditionals
> around "INSTALL_FOO" and simply install it. It doesn´t harm
> the final user as packagers will strip down as necessary
> and makes the build system incredibly simpler.
> Simplicity will also reflect in the spec file.
>
> - porting of qdisk to votequorum and eventually finalize qdevice API
> in votequorum.
>
yes
> - support more encryption methods (other than none/aes256) from nss.
>
yes
> - libtotem cleanup/rewrite (3.x)
> During the last phase of 2.0 devel, we did hit a few limitations
> on what we could fix and how due to the way libtotem layers
> call each other. We should evaluate and consider to simplify those
> layers and make code easier to maintain.
> Simplification will give us also the option to improve runtime
> reconfiguration of totem (right now very limited).
>
no
Totem was incredibly painful to write and debug. Not broken, don't fix.
I personally believe totem below totempg layer is nearly perfect with
exception of few nitpicks like the bind issue and kernel loopback
requirement.
The top layer of the stack (totempg) needs a good beating. It is not 64
bit aligned, and the interface itself is muddy. This
fragmentation/assembly should likely be rewritten at some point, but
that will break compatibility. I'd even support a needle rewrite of the
implementation if there was a "enable-next-gen-fragmentation" option
added (while keeping the previous around).
Also there should be a layer between process groups and fragmentation
(ie: totempg, that calls totemfrg, that calls totemsrp).
I understand that dynamic config becomes more difficult with this
layered approach. But the linux ip stack in linux supports it quite
well via getops/setops. Perhaps we copy that design.
Surgical changes may make more sense - could you propose those instead?
Thanks
-steve
> _______________________________________________
> discuss mailing list
> discuss@xxxxxxxxxxxx
> http://lists.corosync.org/mailman/listinfo/discuss
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
