netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RTNETLINK] Convert RTM_* to enum
@ 2004-09-15  2:09 Herbert Xu
  2004-09-15  3:38 ` James Morris
  2004-09-16  9:08 ` [RTNETLINK] Tunnel config via netlink (Was Re: Convert RTM_* to enum) Ville Nuorvala
  0 siblings, 2 replies; 8+ messages in thread
From: Herbert Xu @ 2004-09-15  2:09 UTC (permalink / raw)
  To: David S. Miller, YOSHIFUJI Hideaki, James Morris, netdev

[-- Attachment #1: Type: text/plain, Size: 430 bytes --]

Hi:

I decided to bite the bullet and use netlink for the tunnel operations.
Before I do that, here is a patch to convert the RTM_* constants to an
enum.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[-- Attachment #2: p --]
[-- Type: text/plain, Size: 3396 bytes --]

===== include/linux/rtnetlink.h 1.43 vs edited =====
--- 1.43/include/linux/rtnetlink.h	2004-09-10 03:24:53 +10:00
+++ edited/include/linux/rtnetlink.h	2004-09-15 11:45:24 +10:00
@@ -9,53 +9,89 @@
 
 /* Types of messages */
 
-#define RTM_BASE	0x10
-
-#define	RTM_NEWLINK	(RTM_BASE+0)
-#define	RTM_DELLINK	(RTM_BASE+1)
-#define	RTM_GETLINK	(RTM_BASE+2)
-#define	RTM_SETLINK	(RTM_BASE+3)
-
-#define	RTM_NEWADDR	(RTM_BASE+4)
-#define	RTM_DELADDR	(RTM_BASE+5)
-#define	RTM_GETADDR	(RTM_BASE+6)
-
-#define	RTM_NEWROUTE	(RTM_BASE+8)
-#define	RTM_DELROUTE	(RTM_BASE+9)
-#define	RTM_GETROUTE	(RTM_BASE+10)
-
-#define	RTM_NEWNEIGH	(RTM_BASE+12)
-#define	RTM_DELNEIGH	(RTM_BASE+13)
-#define	RTM_GETNEIGH	(RTM_BASE+14)
-
-#define	RTM_NEWRULE	(RTM_BASE+16)
-#define	RTM_DELRULE	(RTM_BASE+17)
-#define	RTM_GETRULE	(RTM_BASE+18)
-
-#define	RTM_NEWQDISC	(RTM_BASE+20)
-#define	RTM_DELQDISC	(RTM_BASE+21)
-#define	RTM_GETQDISC	(RTM_BASE+22)
-
-#define	RTM_NEWTCLASS	(RTM_BASE+24)
-#define	RTM_DELTCLASS	(RTM_BASE+25)
-#define	RTM_GETTCLASS	(RTM_BASE+26)
-
-#define	RTM_NEWTFILTER	(RTM_BASE+28)
-#define	RTM_DELTFILTER	(RTM_BASE+29)
-#define	RTM_GETTFILTER	(RTM_BASE+30)
-
-#define RTM_NEWACTION   (RTM_BASE+32)
-#define RTM_DELACTION   (RTM_BASE+33)
-#define RTM_GETACTION   (RTM_BASE+34)
-
-#define RTM_NEWPREFIX	(RTM_BASE+36)
-#define RTM_GETPREFIX	(RTM_BASE+38)
-
-#define	RTM_GETMULTICAST (RTM_BASE+42)
-
-#define	RTM_GETANYCAST	(RTM_BASE+46)
-
-#define	RTM_MAX		(RTM_BASE+47)
+enum {
+	RTM_BASE	= 16,
+#define RTM_BASE	RTM_BASE
+
+	RTM_NEWLINK	= 16,
+#define RTM_NEWLINK	RTM_NEWLINK
+	RTM_DELLINK,
+#define RTM_DELLINK	RTM_DELLINK
+	RTM_GETLINK,
+#define RTM_GETLINK	RTM_GETLINK
+	RTM_SETLINK,
+#define RTM_SETLINK	RTM_SETLINK
+
+	RTM_NEWADDR	= 20,
+#define RTM_NEWADDR	RTM_NEWADDR
+	RTM_DELADDR,
+#define RTM_DELADDR	RTM_DELADDR
+	RTM_GETADDR,
+#define RTM_GETADDR	RTM_GETADDR
+
+	RTM_NEWROUTE	= 24,
+#define RTM_NEWROUTE	RTM_NEWROUTE
+	RTM_DELROUTE,
+#define RTM_DELROUTE	RTM_DELROUTE
+	RTM_GETROUTE,
+#define RTM_GETROUTE	RTM_GETROUTE
+
+	RTM_NEWNEIGH	= 28,
+#define RTM_NEWNEIGH	RTM_NEWNEIGH
+	RTM_DELNEIGH,
+#define RTM_DELNEIGH	RTM_DELNEIGH
+	RTM_GETNEIGH,
+#define RTM_GETNEIGH	RTM_GETNEIGH
+
+	RTM_NEWRULE	= 32,
+#define RTM_NEWRULE	RTM_NEWRULE
+	RTM_DELRULE,
+#define RTM_DELRULE	RTM_DELRULE
+	RTM_GETRULE,
+#define RTM_GETRULE	RTM_GETRULE
+
+	RTM_NEWQDISC	= 36,
+#define RTM_NEWQDISC	RTM_NEWQDISC
+	RTM_DELQDISC,
+#define RTM_DELQDISC	RTM_DELQDISC
+	RTM_GETQDISC,
+#define RTM_GETQDISC	RTM_GETQDISC
+
+	RTM_NEWTCLASS	= 40,
+#define RTM_NEWTCLASS	RTM_NEWTCLASS
+	RTM_DELTCLASS,
+#define RTM_DELTCLASS	RTM_DELTCLASS
+	RTM_GETTCLASS,
+#define RTM_GETTCLASS	RTM_GETTCLASS
+
+	RTM_NEWTFILTER	= 44,
+#define RTM_NEWTFILTER	RTM_NEWTFILTER
+	RTM_DELTFILTER,
+#define RTM_DELTFILTER	RTM_DELTFILTER
+	RTM_GETTFILTER,
+#define RTM_GETTFILTER	RTM_GETTFILTER
+
+	RTM_NEWACTION	= 48,
+#define RTM_NEWACTION   RTM_NEWACTION
+	RTM_DELACTION,
+#define RTM_DELACTION   RTM_DELACTION
+	RTM_GETACTION,
+#define RTM_GETACTION   RTM_GETACTION
+
+	RTM_NEWPREFIX	= 52,
+#define RTM_NEWPREFIX	RTM_NEWPREFIX
+	RTM_GETPREFIX	= 54,
+#define RTM_GETPREFIX	RTM_GETPREFIX
+
+	RTM_GETMULTICAST = 58,
+#define RTM_GETMULTICAST RTM_GETMULTICAST
+
+	RTM_GETANYCAST	= 62,
+#define RTM_GETANYCAST	RTM_GETANYCAST
+
+	RTM_MAX,
+#define RTM_MAX		RTM_MAX
+};
 
 /* 
    Generic structure for encapsulation of optional route information.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RTNETLINK] Convert RTM_* to enum
  2004-09-15  2:09 [RTNETLINK] Convert RTM_* to enum Herbert Xu
@ 2004-09-15  3:38 ` James Morris
  2004-09-15  3:47   ` Herbert Xu
  2004-09-16  9:08 ` [RTNETLINK] Tunnel config via netlink (Was Re: Convert RTM_* to enum) Ville Nuorvala
  1 sibling, 1 reply; 8+ messages in thread
From: James Morris @ 2004-09-15  3:38 UTC (permalink / raw)
  To: Herbert Xu; +Cc: David S. Miller, YOSHIFUJI Hideaki, netdev

On Wed, 15 Sep 2004, Herbert Xu wrote:

> I decided to bite the bullet and use netlink for the tunnel operations.
> Before I do that, here is a patch to convert the RTM_* constants to an
> enum.

Having the enums as well as the defines is messy, I wonder if it's really
worth it.


- James
-- 
James Morris
<jmorris@redhat.com>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RTNETLINK] Convert RTM_* to enum
  2004-09-15  3:38 ` James Morris
@ 2004-09-15  3:47   ` Herbert Xu
  2004-09-15  4:38     ` David S. Miller
  0 siblings, 1 reply; 8+ messages in thread
From: Herbert Xu @ 2004-09-15  3:47 UTC (permalink / raw)
  To: James Morris; +Cc: David S. Miller, YOSHIFUJI Hideaki, netdev

On Tue, Sep 14, 2004 at 11:38:21PM -0400, James Morris wrote:
> 
> Having the enums as well as the defines is messy, I wonder if it's really
> worth it.

I think the enum is definitely worth it for reducing the churn on
the MAX value.

I personally don't see a point to the defines since the user-space
appliations should not change behaviour based on compile-time
settings.  However, others seem to have a different opinion on that.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RTNETLINK] Convert RTM_* to enum
  2004-09-15  3:47   ` Herbert Xu
@ 2004-09-15  4:38     ` David S. Miller
  2004-09-15  4:45       ` Herbert Xu
  0 siblings, 1 reply; 8+ messages in thread
From: David S. Miller @ 2004-09-15  4:38 UTC (permalink / raw)
  To: Herbert Xu; +Cc: jmorris, yoshfuji, netdev

On Wed, 15 Sep 2004 13:47:48 +1000
Herbert Xu <herbert@gondor.apana.org.au> wrote:

> On Tue, Sep 14, 2004 at 11:38:21PM -0400, James Morris wrote:
> > 
> > Having the enums as well as the defines is messy, I wonder if it's really
> > worth it.
> 
> I think the enum is definitely worth it for reducing the churn on
> the MAX value.
> 
> I personally don't see a point to the defines since the user-space
> appliations should not change behaviour based on compile-time
> settings.  However, others seem to have a different opinion on that.

Right.  If we start using defines we have to keep them around.
I know it's bogus for people to ifdef this stuff, but we know
they do, and it's in bad taste to knowingly break stuff like that.

Anyways, I'll apply your patch Herbert, thanks.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RTNETLINK] Convert RTM_* to enum
  2004-09-15  4:38     ` David S. Miller
@ 2004-09-15  4:45       ` Herbert Xu
  2004-09-15  4:46         ` David S. Miller
  0 siblings, 1 reply; 8+ messages in thread
From: Herbert Xu @ 2004-09-15  4:45 UTC (permalink / raw)
  To: David S. Miller; +Cc: jmorris, yoshfuji, netdev

On Tue, Sep 14, 2004 at 09:38:37PM -0700, David S. Miller wrote:
> 
> Right.  If we start using defines we have to keep them around.
> I know it's bogus for people to ifdef this stuff, but we know
> they do, and it's in bad taste to knowingly break stuff like that.

How about if we make it a rule that we only add new enum constants
but not macros?

> Anyways, I'll apply your patch Herbert, thanks.

Thanks.
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RTNETLINK] Convert RTM_* to enum
  2004-09-15  4:45       ` Herbert Xu
@ 2004-09-15  4:46         ` David S. Miller
  0 siblings, 0 replies; 8+ messages in thread
From: David S. Miller @ 2004-09-15  4:46 UTC (permalink / raw)
  To: Herbert Xu; +Cc: jmorris, yoshfuji, netdev

On Wed, 15 Sep 2004 14:45:55 +1000
Herbert Xu <herbert@gondor.apana.org.au> wrote:

> On Tue, Sep 14, 2004 at 09:38:37PM -0700, David S. Miller wrote:
> > 
> > Right.  If we start using defines we have to keep them around.
> > I know it's bogus for people to ifdef this stuff, but we know
> > they do, and it's in bad taste to knowingly break stuff like that.
> 
> How about if we make it a rule that we only add new enum constants
> but not macros?

If you create some new enumeration from scratch, sure, but
for existing ones no.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [RTNETLINK] Tunnel config via netlink (Was Re: Convert RTM_* to enum)
  2004-09-15  2:09 [RTNETLINK] Convert RTM_* to enum Herbert Xu
  2004-09-15  3:38 ` James Morris
@ 2004-09-16  9:08 ` Ville Nuorvala
  2004-09-16 11:13   ` Pekka Savola
  1 sibling, 1 reply; 8+ messages in thread
From: Ville Nuorvala @ 2004-09-16  9:08 UTC (permalink / raw)
  To: Herbert Xu; +Cc: David S. Miller, YOSHIFUJI Hideaki, James Morris, netdev

On Wed, 15 Sep 2004, Herbert Xu wrote:

> I decided to bite the bullet and use netlink for the tunnel operations.

It's great if you have the time and energy to do this! Let me know if I
can be of any assistance with the ip6_tunnel.c modifications.

While designing the netlink interface it might perhaps be a good idea to
take a look at draft-ietf-ipv6-inet-tunnel-mib-02.txt, which is currently
in IESG processing. The IPv6 specific tunnel encapsulation limit (below)
is still missing from the draft but will be included in the RFC.

tunnelIfEncapsLimit OBJECT-TYPE
    SYNTAX     Integer32 (-1 | 0..255)
    MAX-ACCESS read-write
    STATUS     current
    DESCRIPTION
            "The maximum number of additional encapsulations permitted
            for packets undergoing encapsulation at this node.  A value
            of -1 indicates that no limit is present (except as a result
            of the packet size)."
    REFERENCE  "RFC 2473, section 4.1.1"
    ::= { tunnelIfEntry 11 }

Regards,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RTNETLINK] Tunnel config via netlink (Was Re: Convert RTM_* to enum)
  2004-09-16  9:08 ` [RTNETLINK] Tunnel config via netlink (Was Re: Convert RTM_* to enum) Ville Nuorvala
@ 2004-09-16 11:13   ` Pekka Savola
  0 siblings, 0 replies; 8+ messages in thread
From: Pekka Savola @ 2004-09-16 11:13 UTC (permalink / raw)
  To: Ville Nuorvala
  Cc: Herbert Xu, David S. Miller, YOSHIFUJI Hideaki, James Morris,
	netdev

On Thu, 16 Sep 2004, Ville Nuorvala wrote:
> While designing the netlink interface it might perhaps be a good idea to
> take a look at draft-ietf-ipv6-inet-tunnel-mib-02.txt, which is currently
> in IESG processing. The IPv6 specific tunnel encapsulation limit (below)
> is still missing from the draft but will be included in the RFC.
> 
> tunnelIfEncapsLimit OBJECT-TYPE
>     SYNTAX     Integer32 (-1 | 0..255)
>     MAX-ACCESS read-write
>     STATUS     current
>     DESCRIPTION
>             "The maximum number of additional encapsulations permitted
>             for packets undergoing encapsulation at this node.  A value
>             of -1 indicates that no limit is present (except as a result
>             of the packet size)."
>     REFERENCE  "RFC 2473, section 4.1.1"
>     ::= { tunnelIfEntry 11 }

FWIW, I've always viewed this as a mostly unnecessary feature that
nobody bothers to implement, but YMMV.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2004-09-16 11:13 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-09-15  2:09 [RTNETLINK] Convert RTM_* to enum Herbert Xu
2004-09-15  3:38 ` James Morris
2004-09-15  3:47   ` Herbert Xu
2004-09-15  4:38     ` David S. Miller
2004-09-15  4:45       ` Herbert Xu
2004-09-15  4:46         ` David S. Miller
2004-09-16  9:08 ` [RTNETLINK] Tunnel config via netlink (Was Re: Convert RTM_* to enum) Ville Nuorvala
2004-09-16 11:13   ` Pekka Savola

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).