[INET] Add flags field to ip_tunnel_parm

Hi:

This patch adds a new flags field to struct ip_tunnel_parm.

The reason is that one of its users, ip_gre cannot place any new flags
in the existing fields.  i_flags is unuseable for GRE because any future
GRE extension may use one of those bits.

Of course we'll need new flags to implement the DSCP options as we
did for ip6_tunnel.

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

BTW if anyone else wants to add more fields to the structure, now is
the time.

Another thing, the iptnl_* functions turn out to be fairly big.
So I'd like to uninline them.  Unfortunately I can't think of a
good place to put them.

Should I:

1) Put it into ipip.c and make the others depend on it.
2) Put it into xfrm4_tunnel.c and make the others depend on it.
3) Put it into some other file in net/ipv4 that's always built in.
4) Create a new module just for this (and any other shared code between them).
5) Replace inline with __attribute__ ((__unused__)).
6) Stop thinking about this and do something useful :)

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

In article [off-list ref] (at Tue, 14 Sep 2004 22:16:17 +1000), Herbert Xu [off-list ref] says:

BTW if anyone else wants to add more fields to the structure, now is
the time.

Well, you simply cannot do this.

Kernel will get garbage from old binaries,
and kernel will break user space if it tries 
to get params into old structure.

So, please change SIOxxxTUNNEL values to support both interfaces
(or give up ioctl and use rtnetlink instead!)

Thanks.

-- 
Hideaki YOSHIFUJI @ USAGI Project [off-list ref]
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

On Tue, 14 Sep 2004, Herbert Xu wrote:

3) Put it into some other file in net/ipv4 that's always built in.

I'd suggest net/ipv4/ip_tunnel.c



- James
-- 
James Morris
[off-list ref]

On Tue, Sep 14, 2004 at 09:52:05PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:

Kernel will get garbage from old binaries,
and kernel will break user space if it tries 
to get params into old structure.

The only application that I know of does a memset on the structure
so it'll be fine.  Are you aware of any user-space applications that
initialises every field explicitly instead of using memset?

There are two in-kernel users as well (ipmr/addrconf) and they both
initialise it with memset too.

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

On Wed, Sep 15, 2004 at 07:28:43AM +1000, herbert wrote:

On Tue, Sep 14, 2004 at 09:52:05PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:

quoted

Kernel will get garbage from old binaries,
and kernel will break user space if it tries 
to get params into old structure.

The only application that I know of does a memset on the structure
so it'll be fine.  Are you aware of any user-space applications that
initialises every field explicitly instead of using memset?

Never mind, I see what you mean now.

I suppose change the ioctl names/numbers is the easiest way now.
I'd love to use netlink but that seems to require a lot of
infrastructure which isn't there currently.
 
Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt