> >> 	should we retire greconfig(8), or keep it for backward compat?
> >I'd say retire it (like we did with gifconfig).

I think, as well as "rewrite if_gre.[ch] and ip_gre.[ch]", "rewrite
greconfig" is better.

e.g., "ifconfig gre?" with some special argument will setup "protocol
type", not only inet/inet6 but ethernet transparent bridging etc.? It
will also setup "version number"?
In addition, although I'm not completely sure, GRE may need to setup
some "key present" in a header for some protocol, like MobileIP.
GRE has several own characters.

This would be a different issue, though, both of dynamic (via APIs)
and static (via greconfig) configurations might be useful for GRE.
(I'm sorry I don't know how current implementation, e.g., PPTP uses
GRE. Each daemon encapslates packets within GRE by itself? Is it no
benefit to do it using some APIs implemented in kernel?)

> 	one mystery for me is that gre(4) uses 2 bit (link0/link2) to select
> 	from two operation modes.  1 bit should be enough... should we
> 	retire the use of link2 too?  it won't impact existing implementations
> 	(due to the way it is documented/implemented)

IMO, from the view of the meaning, using link0/link2 seems incorrect.
(It currently defines "protocol type".)
So, again, rewiting if_gre.[ch], ip_gre.[ch] and greconfig seems fine
for me.

Since I tried to rewrite greconfig.c, if_gre.[ch] and ip_gre.[ch]
about two years ago, I may be able to cooperate with you, if you
expect it's worth rewriting them.
--
Hitoshi Asaeda