On Mon, 2010-05-03 at 07:21 -0700, Dan Smith wrote: > 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? I may not have made my point earlier: Let me give you an example by looking at your migration attributes.. ----- + __be32 inet4_len; /* mask length (bits)*/ + __u32 inet4_met; /* metric */ + __be32 inet4_dst; /* route address */ + __be32 inet4_gwy; /* gateway address */ ----- At some point i had a discussion with some folks on netdev where it seemed valueable to add a fwmark to the route. If such is made, I dont see what the motivation for whoever is codifying to add it to your attributes so you can migrate the fwmark. One good motivation is to make sure the main route code fails to compile if your attributes dont get modified - this could happen if you re-use the same data structures as the kernel etc. > 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). True - but you still need to worry about compat issues etc i.e when you migrate to a remote kernel they better have the same features and kernel config.. I am assuming this is not hard to impose on an admin. Doing things in user space allows for doing more interesting things like negotiating on capabilities etc > 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... Maybe the answer is to start by formalizing that, not sure. cheers, jamal _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers