On 04/14/2012 05:57 PM, Steven Dake wrote:
> 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.
It doesn't affect code, we only move it around in the tree basically.
Plus the minor Makefile changes. Either way, I don't have a strong
opinion on when it should happen, I would like to see it more "clean" at
some point. Let see what Honza has to say.
>> - 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 problem is that by default we don't cross all the build paths. This
has lead to problems between upstream release and fedora updates where
we build everything. That's why I want this aligned properly.
> The current system makes perfect sense.
No it doesn't :) but we can argue "yes" "no" forever.
> 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?
Fairly simple really. None of our features are "maybe" state.
Let's take 2 simple examples:
- rdma: Either the distro/hardware supports it or not.
- systemd: it doesn't change code build or path, we simply install
2/3 more files in systemd service dir. Distro can decide
to ship it if they support systemd or not.
This really boils down to basic packaging knowledge.
>
>> 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.
Most of those were examples really. I didn't investigate every single
bit and piece everywhere. It was mostly to give the idea.
>
>> - 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.
Well not really, because we enable everything by default when building
Fedora. So there is a discrepancy in the message we are sending out.
>> - 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?
We might be able to do surgical, but so far Honza and I had to give up
changing already 2 config options because the amount of code to change
is too complex and cross layered (layer A -> layer B -> layer C -> layer
A -> layer D .. you get the idea..).
and surgical will require some extra analysis of what we want to achieve
in more details. My idea was to get as close as possible to 100% runtime
reconfig and to drop all malloc/alloca/memcpy to the lowest number possible.
The idea of getops/setops is no different than triggered cmap changes.
The problem is the amount of code paths that relies on static
pre-defined values.
Fabio
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
