Subject: Re: Full story on PFIL_HOOKS rearrangement
To: Jason R Thorpe <thorpej@zembu.com>
From: Aidan Cully <aidan@kublai.com>
List: tech-net
Date: 11/10/2000 22:50:34
On Thu, Nov 09, 2000 at 11:55:36PM -0800, Jason R Thorpe wrote:
> The diff below includes some things I previously talked about -- the
> placement of the PFIL_HOOKS calls.  Here is also changes to make the
> mechanism more generic -- you can have multiple hook heads -- they're
> registered with a "key" and "dlt" pair.
> 
> Key is a void * (so it could be e.g. a network interface structure; this
> gets into my classification engine, which I'll describe in more detail
> later).  DLT is a BPF DLT constant that indicates what kind of link
> level header is present.
> 
> For INET and INET6, the keys are ((void *) AF_INET) and ((void *) AF_INET6),
> and the DLT is DLT_RAW (since there is no link level header present when
> the packets are handed off to the filter).

I note that I'm not a kernel or networking guy, and acknowledge that
in practice this probably won't lose, but it strikes me as a mistake
to create a void * key by typecasting integers...  It looks like the
void *'s are supposed to be globally unique?  Taking the address of
a kernel variable buys you that automatically, but by using integers,
you'd need to verify each time you added a new integer key that it
doesn't clash with old keys.  Like I say, I acknowledge that it likely
won't be a problem (since you'll probably stick to address families,
when using integer keys), but it still bothers me.

Any reason not to do
extern int _pfil_inet4_key;
#define PFIL_INET4_KEY	((void *) &_pfil_inet4_key)
and similar for INET6?

--aidan