[PATCH] entry_data

[Patrick McHardy]

Massimiliano Hofer wrote:
> I changed the API on the (possibly wrong) assumption that most modules will 
> need it for shared data (that's what I and at least some other modules need), 
> but thinking about it there are other uses (multiple data with different 
> sharing, non shared data that has no business in the userspace struct, etc.). 
> In other words, you're right.
> 
> Following your suggestion I could add a .priv_size field and if it is non zero 
> I allocate the requested memory and pass it as void * (the same type passed 
> to (*checkentry)(), (*destroy)() and (*match)()).
> 
> We have 2 ways to implement this:
> - we can allocate priv_size more bytes after data;
> - we can separately allocate priv_size bytes and store a pointer in 
> u.kernel.entry_data.
> 
> Seeing how the initialization code works, the first one is a bit hairy. The 
> latter is really easy to implement, but if someone just needs 4 bytes we end 
> up storing a pointer to a pointer with no good reason.


The case of just needing a pointer is just an optimization for a
special-case in my opinion (avoid lookup of globally shared state),
per-instance state is probably more common. So I'd suggest to go
with the second possibility.