Subject: Re: Full story on PFIL_HOOKS rearrangement
To: Jason R Thorpe <firstname.lastname@example.org>
From: Aidan Cully <email@example.com>
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?