You do not explain why we (or kernel) NEED(s) this. It is not so important how SMALL it is though it may cause problems how LARGE it is.
I had explained the reasons for having prefix list i/f in my previous mail. To recap : - User don't need to know what the definition of a prefix is, all he has to do is ask the kernel and get the list. Otherwise different user apps will have to know the definition of a prefix and parse the entry themselves. The parsing is non-trivial (eg the address should not LL or MC, there should be no nexthop and it should be added via an RA, etc). - The kernel code to get the prefix list is small, the top level inet6_dump_fib uses either the dump_node or the dump_prefix, the latter being the new user interface. Having a user interface makes it easier to get the prefix list without significant bloat to the kernel.
This is design issue; how we should provide L3 per-interface information to userspace; eg. in_device and/or inet6_dev things including per-interface statistics.
Since I think it is not appropriate to provide per-interface statistics via RTM_xxxROUTE, so I don't agree to provide the RA infomation (i.e. Manage/Otherconf Flags) via RTM_xxxROUTE.
Options: - use RTM_xxxLINK for L3 operation - introduce RTM_xxxIFACE for L3 per-interface operations
Yes, there are a couple of different ways to do this. One is as you have suggested, but there is a problem with it. The existing RTM_GETLINK interface returns very generic elements of the dev (mtu, hardware address, dev statistics), while the change you suggested is specific to ipv6. I am not sure if this is a good design to implement. Either we could use the current (submitted) way or use a different RTM_GETADDR interface in inet6_fill_ifaddr (and introduce RTM_IFACEFLAGS). This will be specific to IPv6. Are you agreeable to this ?
Well, on moving forward; you can split your patch up to 3 things: 1. fix routing flags 2. provide Managed/Otherconf flags API (3. provide the prefix list API (if it IS required))
I'm not against the first item. We need to discuss on the design related to the 2nd item. I don't think that we really need 3rd item.
- I am ok with 1 :-) - I have suggested changes for 2, please let me know what you think, whether we can go with the old way or make the change suggested above. - I believe we need #3 for the reasons given above.
Thanks,
- KK
- : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
