Subject: Re: ipfilter 3.4beta - ipv6 filtering.
To: Darren Reed <email@example.com>
From: Christian E. Hopps <firstname.lastname@example.org>
Date: 02/21/2000 03:34:19
Darren Reed <email@example.com> writes:
> In some email I received from Jason Thorpe, sie wrote:
> > When you set the rules (which doesn't happen very often), you have in
> > the ioctl a "struct sockaddr *addr" and a "size_t addrlen" (like, say,
> > the bind(2) system call does). You copy in that sockaddr separately.
> > You then convert the data in that sockaddr into the internal representation
> > you wish to use.
> > This gives you:
> > - flexibility (when new IP versions come along, for example). Why
> > do you care about this? Well, even though you claim that IP Filter
> > was originally for IPv4 only, you obviously saw some value in
> > adding IPv6 support, so why not take the opportunity to fix
> > a simple bogon in the ioctl interface to make it easier to add
> > support for some other address family which you might find useful
> > to use in the future?
> > - performance -- you're still using your regular internal
> > representation on the inside, *not sockaddrs*.
> The structure which would hold the pointers to the sockaddr's is the same
> one which holds the end addresses. That is, when a filter rule is loaded,
> the entire struct is passed straight into the kernel which looks up
> interface names and links it up to groups, etc. All of the IP addresses
> and ports used in doing the checks are stored in that single struct.
So the point jason is making is this:
Pass a pointer to the sockaddr, copy it into your happy structure you
have now.. Don't poluute the API into the kernel with protocol specific
This change is so simple why are you fighting it?