|
On Fri, 2008-08-22 at 11:56 +0200, Julius Volz wrote:
> There's also a '__u8 reserved' field at the beginning of that struct
> which could be used. But in general, is it reasonable to expect both
> nodes to use the same kernel version, which gets rid of the
> extensibility problems? It's not really an ABI that can't be broken,
> right?
I think from an operational (ie. end user) perspective, ABI breakage is
something to try to avoid but _not_ at all costs.
If it's possible to extend the sync daemon protocol by reusing the
existing code and ABI, all well and good; however if a fundamental
change is made which breaks the old sync daemon ABI then as long as it's
documented and we make sure that users know to have the same (or higher)
kernel versions on their directors then everyone wins.
> Yes, without jumping through hoops, we have to probably break the
> current protocol anyways for new features? Even if we designated
> unused fields for new information, an old kernel will not look at them
> / fill them out, which limits the possibilities...
I guess that as and when this change is made and gets into mainline
releases, Joe and I will have to have a mantra of "ensure your directors
are using the same kernel version" in response to queries on
lvs-users :)
Graeme
--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|
