|
On Thu, Sep 02, 2010 at 03:16:40AM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Wed, 1 Sep 2010, Simon Horman wrote:
>
> > On the kernel-side of things, internally it should be easy
> > enough to either expand flags or add a new element to the structure.
> > So it seems to me that the problem is the kernel/user-space interface.
> > And if that is the case, I think the best idea is to just use
> > the netlink interface for all new configuration options and have
> > new features unsupported through the old, legacy, ioctl interface.
>
> No, there should be no problem with the interface,
> it already uses 32 bits. We should change only cp->flags
> to 32 bits and new flags should go after bit 16 if they
> are not needed for sync. Some flags can be changed safely,
> for example, IP_VS_CONN_F_SYNC: it is not used by ipvsadm,
> it is set only in backup, so it can be moved after bit 16.
> May be another idea is to create 2nd version for the
> struct ip_vs_sync_conn to support more features.
I think that your idea of moving flags that don't need to be in the lower
16 bits to the upper 16 bits, and having a policy for new flags is fine.
We can create a second version of ip_vs_sync_conn later if we need to.
--
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
|
