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
families.
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
overkill.
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> http://www.netfilter.org/
============================================================================
"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
signature.asc
Description: Digital signature
|