All of lore.kernel.org
 help / color / mirror / Atom feed
From: Herve Eychenne <rv@wallfire.org>
To: Henrik Nordstrom <hno@marasystems.com>
Cc: Netfilter Development Mailinglist <netfilter-devel@lists.netfilter.org>
Subject: Re: Future of CONNMARK (was Re: MASQUERADE: Route sent us somewhere else (was Re: Fw: Rusty's brain broke!)
Date: Wed, 21 Jan 2004 00:21:03 +0100	[thread overview]
Message-ID: <20040120232103.GB1143@eychenne.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0401200743490.23963-100000@filer.marasystems.com>

On Tue, Jan 20, 2004 at 08:05:45AM +0100, Henrik Nordstrom wrote:

> On Tue, 20 Jan 2004, Herve Eychenne wrote:

> > Yes, as it is always some kind of "static".
> > You'll note that the reason why I prefer a program to a "static" (even
> > if generated at iptables compile time) manpage is that the manpage will
> > not reflect your current combination (at least durably), again.

> But with iptables the best level or program is the same as you get with 
> the proposed patch, the manpage reflects what your userspace binary 
> supports, independent of what the kernel supports.

Yes, and that is another question I want to raise...
I don't really understand why p-o-m would not add both parts (kernel/user).
That would mean not distributing an iptables tarball with every
extensions. According to me, adding an extension should be treated
equally on user and kernel sides (as they are heavily coupled).

> Actually, fixing the error message is not hard, but it requires some sligt 
> additions to the kernel to allow querying if a given target/match is 
> supported so users of old kernels will have to live with the obscure 
> error even after the problem has been addressed.

Why isn't this done already? ;-)

> > Please note that I do not suggest this shouldn't be done. If we write
> > the program I'm talking about, it will be perfectly feasible (and
> > it should be done) to generate a document (manpage, or other)
> > documented every existing module.

> What I don't get is what this program approach gives which the 
> at-compiletime build of the manpage does not.

If you think of the current scheme, where you're forced to recompile
userspace after having used patch-o-matic, not so much: filtering
capabilities... (mainstream or not, match or target, specific version
or all, currently available or not, etc.). 
A way to know all that is available in every kind of context is needed
anyway, independantly of the documentation, anyway.

> > That doesn't prevent from providing a program which generates a
> > manpage dynamically (if you really want it in a manpage format)...

> Not easily in a way which allows the manpage to be packaged I think.

Packaged in the sense of a distribution package?
Well... the "extension" manpage would simply not be part of the
package itself (which is static, by essence)... but the package would
include the doc (manpage, if we want) generator.

> In addition it does not solve the problem of userspace/kernel mismatches (see 
> below).

> > Yes. That state is not always that clear. For example, a feature could belong to
> > p-o-m for a certain kernel version, and mainstream for kernel version + 1.
> > But! You (netfilter developer) perfectly know what this is all about.

> So then we should try to have this better documented than it is today.  
> Mentioning p-o-m in the iptables documentation would be a start..

p-o-m is already mentionned, but in the netfilter extensions HOWTO, I
think. It is not mentionned in the manpage, but iptables manpage is
about userspace anyway. And that has been a moment since I think that
there really should be a manpage about userspace (iptables), a manpage
about kernel (there are some things to tell, and I have started one,
which I'll sent in a few days), and one about extensions.

> > I do not understand. A manpage with every extensions will only tell
> > you what you could have, and you would have to experiment quite much
> > (with uninformative error messages) to know what you can really _use_.

> What I propose is a manpage with

> a) Every extension which is known to your userspace binary (i.e. the 
> extensions which was enabled in the kernel the binary is built for)

> b) In addition, the documentation for the extensions (where such
> documentation exists) you could have with documentation on how you get
> these from p-o-m if you need them. This could be in the same page or a
> different page if having them in the same page may confuse people (I think 
> not, but I am not the average user)

> Not a dumb page where all extensions is documented as if they were 
> supported on the users system.

If we really want a userspace-compile-time-built manpage, then yes,
probably.

> > And this is all to be done again when you upgrade the kernel...

> Yes, and the iptables binary needs to be rebuilt as well to add binary 
> support for the added/changed matches/targets. This is the current state 
> of affairs anyway.

Yes, but that should be different. There's unfortunately no easy way
to have a good module management system (fast adding, no recompilation
needed, no binary interface problems) for iptables. :-(  (pkttables
will be the place to do that, as we discussed during the workshop)

 Herve

-- 
 _
(°=  Hervé Eychenne
//)
v_/_ WallFire project:  http://www.wallfire.org/

  parent reply	other threads:[~2004-01-20 23:21 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20030725173900.E6E952C2AE@lists.samba.org>
     [not found] ` <200307251756.VAA12609@dub.inr.ac.ru>
2004-01-11 13:01   ` MASQUERADE: Route sent us somewhere else (was Re: Fw: Rusty's brain broke!) Harald Welte
2004-01-11 13:55     ` Julian Anastasov
2004-01-11 21:11       ` Henrik Nordstrom
2004-01-17 11:09         ` Future of CONNMARK (was " Harald Welte
2004-01-17 17:50           ` Henrik Nordstrom
2004-01-17 12:54             ` IP Options with libipq XiChimos
2004-01-21 13:44               ` Harald Welte
2004-01-18 13:20             ` Future of CONNMARK (was Re: MASQUERADE: Route sent us somewhere else (was Re: Fw: Rusty's brain broke!) Harald Welte
2004-01-18 17:16               ` Henrik Nordstrom
2004-01-19 23:15                 ` Herve Eychenne
2004-01-19 23:48                   ` Henrik Nordstrom
2004-01-20  1:13                     ` Herve Eychenne
2004-01-20  7:05                       ` Henrik Nordstrom
2004-01-20  7:12                         ` Henrik Nordstrom
2004-01-20 23:21                         ` Herve Eychenne [this message]
2004-01-20 18:34                           ` Buffer size XiChimos
2004-01-21  0:45                             ` Henrik Nordstrom
2004-01-20 19:58                               ` XiChimos
2004-01-21  2:25                                 ` Henrik Nordstrom
2004-01-21  2:47                                   ` XiChimos
2004-01-21  8:45                                     ` Henrik Nordstrom
2004-01-20 23:55                           ` Future of CONNMARK (was Re: MASQUERADE: Route sent us somewhere else (was Re: Fw: Rusty's brain broke!) Henrik Nordstrom
2004-01-21 23:49                           ` Harald Welte
2004-01-20 13:01                       ` Harald Welte
2004-01-21  0:17                         ` extensions manpage, howto etc Henrik Nordstrom
2004-01-21 22:02                           ` Harald Welte
2004-01-21  0:44                         ` iptables error reporting Henrik Nordstrom
2004-01-21  2:16                         ` iptables extensions manpage Henrik Nordstrom
2004-01-21 22:00                           ` Harald Welte
2004-02-02 23:40                 ` [patch, resent] Updated CONNMARK Henrik Nordstrom
2004-02-03  8:20                   ` Harald Welte
2004-02-03  9:03                     ` Henrik Nordstrom
2004-02-03  9:50                       ` Harald Welte
2004-01-18 19:14               ` iptables extension manpages Henrik Nordstrom
2004-01-17 18:46           ` Future of CONNMARK (was Re: MASQUERADE: Route sent us somewhere else (was Re: Fw: Rusty's brain broke!) Tom Eastep
2004-01-17 23:40             ` Henrik Nordstrom
2004-01-18  0:20               ` Tom Eastep
2004-01-12  1:07       ` Patrick McHardy
2004-01-12  4:30         ` Rusty Russell
2004-01-13  4:30           ` Patrick McHardy
2004-01-13  8:21           ` Julian Anastasov
2004-01-13 11:54           ` Harald Welte
2004-01-14  5:20             ` Rusty Russell
2004-01-12 11:08         ` Julian Anastasov
2004-01-14 16:11     ` kuznet
2004-01-14 23:42       ` Julian Anastasov

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=20040120232103.GB1143@eychenne.org \
    --to=rv@wallfire.org \
    --cc=hno@marasystems.com \
    --cc=netfilter-devel@lists.netfilter.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.