lkml.org 
[lkml]   [2007]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.20-rc4: regression: iptables failed to load rules


On Wed, 10 Jan 2007, Patrick McHardy wrote:
>
> In the x_tables case it really caused a lot of unnecessary confusion,
> the recent connection tracking changes however needed new config
> options since we're keeping the old implementation around for a few more
> releases.

It's too late now, but it _could_ have fairly easily been handled totally
differently: namely by having the user-visible config options be
INDEPENDENT of the actual back-end.

The Kconfig language is actually pretty powerful for configuration issues,
and the way to do this is relatively straightforward:

config CONNTRACK
tristate "Netfilter support"
...

config NEW_CONTRACK_SUPPORT
bool "Layer 3 Independent Connection tracking"
...

config CONNTRACK_MARK
bool 'Connection mark tracking support'
depends on CONNTRACK
...

config OLD_CONNTRACK_MARK
bool
depends on CONNTRACK_MARK && CONNTRACK && !NEW_CONTRACK_SUPPORT
default y

config NEW_CONNTRACK_MARK
bool
depends on CONNTRACK_MARK && CONNTRACK && NEW_CONTRACK_SUPPORT
default y

See? The _user_ just sees a single "CONNTRACK_MARK" option (that just
depends on the *generic* CONNTRACK config option), but then the Kconfig
file splits that into "OLD_CONNTRACK_MARK" or "NEW_CONNTRACK_MARK"
depending on whether "NEW_CONTRACK_SUPPORT" was set or not.

> It probably won't be necessary anymore to make changes like this in
> the future, but in case it is I'll make sure to at least provide
> compatibility options for a few releases.

In general, I'd much rather see the config options impact what the "user
experience" should be. Notice how the above does exactly that: all the
USER really cares about whether the connection marks are enabled or not,
and the "NEW_CONTRACK_SUPPORT" is _not_ part of the user-visible config
(apart from the _one_ question that asks about which implementation you
want to pick), but it is only used to pick which _implementation_ to
choose.

So making the Kconfig files more user-oriented and less implementation-
oriented automatically solves the problem with config options that change
names (because if the effect is the same, it should have the same name -
regardless of how it is implemented!).

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.064 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site