j> The problem as i see it (with all net structures not just routes - j> i was equally pessimistic when i saw those other net structure j> checkpoint/restore changes) is you are faced with a herculean j> high-maintainance effort... You have a separate piece of code j> which populates structures that _you_ maintain for attributes that j> are defined elsewhere by other people. Nobody adding a new j> attribute that is very important to route restoration for example j> is likely to change your code. Unless you tie the two together (so j> changing one forces the coder to change the other). And once j> people deploy kernels it is hard to change. Historically (for j> pragmatic reasons) such rich interfaces sit in user space - much j> easier to update user space. The benefits of doing what we can in userspace are well-understood and arguing for doing so where it makes sense is, of course, a good idea. However, it seems to me that the rtnl interface provides us a reasonable layer of isolation between us and such changes. Am I wrong? The rtnl messages appear to be rather generic and timeless, and in most cases have a significant amount of flexibility with respect to allowing advanced attributes to be ignored (which implies taking the default). In many other areas of C/R we're not so lucky and don't have a well-defined interface for dumping that information out of the kernel... -- Dan Smith IBM Linux Technology Center email: danms@xxxxxxxxxx _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers