Re: priv_data patch

[Massimiliano Hofer <max@nucleus.it>]

On Monday 14 August 2006 3:34 pm, you wrote:

> While merging the priv_data patch I noticed an oversight. Currently,
> when modifying the ruleset, all modules dump their entire state
> (user configuration + internal state kept in the same structure)
> to userspace, which will return it to the kernel. That means for
> example that the limit match will not loose its current state when
> modifying other rules. When we move the state out of the data shared
> with userspace this can't be done anymore, so each modification to
> the table will cause all modules to loose their current state, even
> if they we're not directly affected by the change. We can't break
> this behaviour, so this limits potential users of the priv_data stuff
> to things like hashlimit or recent, which do a lookup of state stored
> completely external from the ruleset (and could use it to cache the
> lookup result). I don't think that this is worth it, we probably need
> to wait until we have a better userspace interface before we can do
> something like this ..

I'm afraid you are right. This limits the usefulness to volatile data that can 
safely be discarded. This can be some sort of disposable statistic or 
performance enhancing cache of data that can be retrieved in other ways.

Without this patch we are condemned to ugly tricks for data needed by 
condition, hashlimit and recent. I think this is useful, but I'll leave it to 
you to decide if it's worth.

Any idea for a better userspace interface?
It's not the first time you tell me that we could have a better "next 
generation" userspace interface. Maybe it's time to start planning.
Does anyone have wishes for new or different ways to do things?

Just an example without proper thought or planning: we could set an optional 
way rules could use to tag themselves and have their data back if they want 
it. As with priv_data this won't benefit everyone. I'll keep thinking of 
better ways.

IMHO a portion of data outside the one passed by userspace (persistent or 
volatile) is a must in the long run and will free us from an arbitrary 
constraint between userspace and kernelspace. I see other people are writing 
matches that rely on separate user input to complete its data (interface 
groups?) and they will need somewhere to store it.

-- 
Saluti,
   Massimiliano Hofer
        Nucleus