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
|