From: Thomas Graf <tgraf@suug.ch>
To: Ville Nuorvala <vnuorval@tcs.hut.fi>
Cc: David Miller <davem@davemloft.net>,
jmorris@namei.org, netdev@vger.kernel.org,
usagi-core@linux-ipv6.org, yoshfuji@linux-ipv6.org,
anttit@tcs.hut.fi
Subject: Re: [RESEND 3/5] [NET]: Protocol Independant Policy Routing Rules Framework
Date: Mon, 31 Jul 2006 17:24:01 +0200 [thread overview]
Message-ID: <20060731152401.GI14627@postel.suug.ch> (raw)
In-Reply-To: <44CE17B6.2070108@tcs.hut.fi>
* Ville Nuorvala <vnuorval@tcs.hut.fi> 2006-07-31 17:46
> > Derived from net/ipv6/fib_rules.c
>
> do you mean net/ipv4/fib_rules.c or net/ipv6/fib6_rules.c? :-)
Hehe, I meant net/ipv4/fib_rules.c :-)
> > +struct fib_rule_hdr
> > +{
> > + __u8 family;
> > + __u8 dst_len;
> > + __u8 src_len;
> > + __u8 tos;
> > +
> > + __u8 table;
> > + __u8 res1; /* reserved */
> > + __u8 res2; /* reserved */
> > + __u8 action;
> > +
> > + __u32 flags;
> > +};
>
> I'm wondering if this is guaranteed to be equvalent to struct rtmsg?
>
> struct rtmsg
> {
> unsigned char rtm_family;
> unsigned char rtm_dst_len;
> unsigned char rtm_src_len;
> unsigned char rtm_tos;
>
> unsigned char rtm_table; /* Routing table id */
> unsigned char rtm_protocol; /* Routing protocol; see below */
> unsigned char rtm_scope; /* See below */
> unsigned char rtm_type; /* See below */
>
> unsigned rtm_flags;
> };
>
> Won't we otherwise be breaking the existing userland interface?
It is equivalent but you're right, it would break userland
interfaces otherwise. I've defined this new header to add
implicit names and stop the confusion with unused fields.
> > +enum
> > +{
> > + FRA_UNSPEC,
> > + FRA_DST, /* destination address */
> > + FRA_SRC, /* source address */
> > + FRA_IFNAME, /* interface name */
> > + FRA_UNUSED1,
> > + FRA_UNUSED2,
> > + FRA_PRIORITY, /* priority/preference */
> > + FRA_UNUSED3,
> > + FRA_UNUSED4,
> > + FRA_UNUSED5,
> > + FRA_FWMARK, /* netfilter mark (IPv4) */
> > + FRA_FLOW, /* flow/class id */
> > + __FRA_MAX
> > +};
> > +
> > +#define FRA_MAX (__FRA_MAX - 1)
> > +
> > +enum
> > +{
> > + FR_ACT_UNSPEC,
> > + FR_ACT_TO_TBL, /* Pass to fixed table */
> > + FR_ACT_RES1,
> > + FR_ACT_RES2,
> > + FR_ACT_RES3,
> > + FR_ACT_RES4,
> > + FR_ACT_BLACKHOLE, /* Drop without notification */
> > + FR_ACT_UNREACHABLE, /* Drop with ENETUNREACH */
> > + FR_ACT_PROHIBIT, /* Drop with EACCES */
> > + __FR_ACT_MAX,
> > +};
> > +
> > +#define FR_ACT_MAX (__FR_ACT_MAX - 1)
> > +
> > +#endif
>
> Shouldn't all these (struct fib_rule_hdr included) actually be defined
> in include/linux/rtnetlink.h?
We used to stuff everything into rtnetlink.h for no good reason. Having
independant include/linux/<subsystem>.h to export the interface to
userspace and include/net/<subsystem>.h to export the kernel interface
instead of contributing to the ifdef hell seems a lot cleaner to me.
next prev parent reply other threads:[~2006-07-31 15:23 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-26 22:11 [RFC] Multiple IPV6 Routing Tables & Policy Routing Thomas Graf
2006-07-26 22:00 ` [PATCH 1/5] [IPV6]: Remove ndiscs rt6_lock dependency Thomas Graf
2006-07-26 22:28 ` David Miller
2006-07-26 23:34 ` Tushar Gohad
2006-07-26 23:34 ` David Miller
2006-07-31 11:01 ` Ville Nuorvala
2006-07-26 22:00 ` [PATCH 2/5] [IPV6]: Multiple Routing Tables Thomas Graf
2006-07-26 22:39 ` David Miller
2006-07-26 22:48 ` Thomas Graf
2006-07-26 22:55 ` David Miller
2006-07-29 4:13 ` YOSHIFUJI Hideaki / 吉藤英明
2006-07-29 4:14 ` David Miller
2006-07-29 4:28 ` YOSHIFUJI Hideaki / 吉藤英明
2006-07-29 10:29 ` Thomas Graf
2006-07-31 13:55 ` Ville Nuorvala
2006-07-31 14:01 ` Herbert Xu
2006-07-31 14:02 ` Herbert Xu
2006-07-31 15:41 ` Thomas Graf
2006-07-31 20:09 ` David Miller
2006-07-31 15:34 ` Thomas Graf
2006-07-26 22:00 ` [PATCH 3/5] [NET]: Protocol Independant Policy Routing Rules Framework Thomas Graf
2006-07-26 22:41 ` David Miller
2006-07-27 5:58 ` James Morris
2006-07-27 6:02 ` David Miller
2006-07-27 22:39 ` [RESEND " Thomas Graf
2006-07-27 22:58 ` Patrick McHardy
2006-07-27 23:17 ` David Miller
2006-07-27 23:31 ` Patrick McHardy
2006-07-28 9:25 ` Martin Josefsson
2006-07-29 1:40 ` Patrick McHardy
2006-07-29 7:25 ` Martin Josefsson
2006-07-27 23:30 ` Patrick McHardy
2006-07-28 10:23 ` Thomas Graf
2006-07-31 14:46 ` Ville Nuorvala
2006-07-31 15:24 ` Thomas Graf [this message]
2006-07-31 18:01 ` Patrick McHardy
2006-07-31 20:01 ` Thomas Graf
2006-07-26 22:00 ` [PATCH 4/5] [IPV6]: Policy Routing Rules Thomas Graf
2006-07-26 22:42 ` David Miller
2006-07-26 23:26 ` David Miller
2006-07-26 23:33 ` David Miller
2006-07-26 23:40 ` David Miller
2006-07-27 22:40 ` [RESEND " Thomas Graf
2006-07-31 14:55 ` Ville Nuorvala
2006-07-26 22:00 ` [PATCH 5/5] [IPV4]: Use Protocol Independant Policy Routing Rules Framework Thomas Graf
2006-07-26 22:43 ` David Miller
2006-07-26 23:47 ` David Miller
2006-07-27 22:40 ` [RESEND " Thomas Graf
2006-07-28 6:10 ` [RFC] Multiple IPV6 Routing Tables & Policy Routing YOSHIFUJI Hideaki / 吉藤英明
2006-07-28 8:23 ` David Miller
2006-07-28 10:32 ` Thomas Graf
2006-07-29 4:27 ` YOSHIFUJI Hideaki / 吉藤英明
2006-07-31 11:01 ` Ville Nuorvala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060731152401.GI14627@postel.suug.ch \
--to=tgraf@suug.ch \
--cc=anttit@tcs.hut.fi \
--cc=davem@davemloft.net \
--cc=jmorris@namei.org \
--cc=netdev@vger.kernel.org \
--cc=usagi-core@linux-ipv6.org \
--cc=vnuorval@tcs.hut.fi \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).