[Top] [All Lists]

Re: [PATCH 2.6] iptables CLUSTERIP target

To: Lars Marowsky-Bree <lmb@xxxxxxx>
Subject: Re: [PATCH 2.6] iptables CLUSTERIP target
From: Harald Welte <laforge@xxxxxxxxxxxxx>
Date: Thu, 21 Oct 2004 16:25:27 +0200
Cc: bert hubert <ahu@xxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, Linux Netdev List <netdev@xxxxxxxxxxx>
In-reply-to: <20041021133346.GL3911@xxxxxxxxxxxxxxxx>
References: <20041020223828.GP19899@xxxxxxxxxxxxxxxxxxxxxxx> <20041021075530.GA1278@xxxxxxxxxxxxx> <20041021091229.GA3551@xxxxxxxxxxxxxxxxxxxxxxx> <20041021110513.GA21579@xxxxxxxxxxxxxxx> <20041021130327.GD3551@xxxxxxxxxxxxxxxxxxxxxxx> <20041021133346.GL3911@xxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040907i
On Thu, Oct 21, 2004 at 03:33:46PM +0200, Lars Marowsky-Bree wrote:

> If the proc file IO for communicating with the module goes away in
> favour of a commandline based add/list/remove/etc interface, that would
> just help to tidy up our code, so it's OK with me.

I'm not a big fan of inventing new kernel/userspace interfaces.  We
don't have any associated device, so we don't have any ioctl()s or stuff
like that.

For supporting two primitive operation, adding a new netlink address
family also isn't worthwhile, especially since we're short of netlink

Using the iptables getsockopt/setsockopt interface also is not possible,
since it cannot be extended.

So instead of introducing a new syscall, I think /proc is just the right
way to deal with this :)

I've now converted it to use seq_file, still need to do some testing.
The initial reason not to use seq_file was that 

1) I thought seq_file files cannot be writeable.  
2) We don't actually need to dump a table with dozesn of entries, just
   a small number of integer numbers, thus seq_file seemed a bit like

This assumption '1' seems to be wrong, I now provide my own write
function to struct file_operations.

Let me give it some testing, I'll re-submit it later today or tomorrow.

> > > And yes, I've received hate mail over this from switch engineers :-)
> > Why is that?  They have to deal with multicast traffic, too...  and I
> > don't really see how this is any different.
> Yeah, but with this they get a whole lot more ;-)

I didn't read any ethernet-related specification that said it is safe to
assume nobody uses multicast.

- Harald Welte <laforge@xxxxxxxxxxxxx>   
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

Attachment: signature.asc
Description: Digital signature

<Prev in Thread] Current Thread [Next in Thread>