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
