Hello.
In article <[EMAIL PROTECTED]> (at Sat, 29 Sep 2007 19:47:20 +0200), Pierre
Ynard <[EMAIL PROTECTED]> says:
> As discussed before, this patch provides userland with a way to access
> relevant options in Router Advertisements, after they are processed and
> validated by the kernel. Extra options are processed in a generic way;
> this patch only exports RDNSS options described in RFC5006, but support
> to control which options are exported could be easily added.
I basically like this approach at first sight.
> which implies that a userland daemon processing RDNSS options needs a
> way to associate the option to the router that sent it, and fetch its
> lifetime. This kind of information could be included in a header in the
> rtnetlink message (in this version of the patch there is none).
> diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
> index dff3192..f69d415 100644
> --- a/include/linux/rtnetlink.h
> +++ b/include/linux/rtnetlink.h
> @@ -97,6 +97,9 @@ enum {
> RTM_SETNEIGHTBL,
> #define RTM_SETNEIGHTBL RTM_SETNEIGHTBL
>
> + RTM_NEWNDUSEROPT = 68,
> +#define RTM_NEWNDUSEROPT RTM_NEWNDUSEROPT
> +
> __RTM_MAX,
Does this imply that we could extend (or reuse) this for all of
NS/NA/RS/RA/Redirect messages? I think you need to include the
code, type and basic semantics of the message.
If this is only for RA, we should say "RTM_NEWRAUSEROPT" or something.
Regards,
--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
