Re: [PATCH 2.6.15.4 1/1][RFC] ipt_owner: inode match supporting both incoming and outgoing packets

[Török Edwin <edwin@gurde.com>]

On Saturday 18 February 2006 15:10, Arjan van de Ven wrote:
> >  As a last resort, I'll try to maintain this as separate patch to be
> > applied to the kernel, but that is something I'd really try to avoid,
> > because:
>
> the problem is this: The export is going away for a reason and not "just
> because". 
I understand that, I didn't say there wasn't a reason for it going away.
> And that reason is that the implementation is going to be 
> radically redone such that this isn't possible anymore. At all.
Could you tell me on which thread is this reimplementation being discussed? 
I'd like to get a more clear picture of what exports I can use, and which 
ones I can't.

Is the sk_sleep field of struct socket going to remain? If yes what am I 
allowed to do with it inside ipt_owner.c?

Can you provide a function (in the new implementation) that at least gives me 
a list of pids that are going to be woken up by data being received on a 
socket? (for the moment it doesn't matter if that function will take some 
time to complete its job, it's still going to be faster, than doing all this 
from userspace). Then I could do the rest of the checking in userspace.

Or if that is not possible, could you tell me what kind of information am I 
going to be able to obtain from the wait_queue_t of the socket?

> No amount of patching can fix that ;)
That is why I started this thread in the first place. I want to implement the 
inode match in such a way that it will use only functions/structures it is 
supposed to, (and not some functions/structures that are going away).

Could you please help me, and tell me _how_  I can implement this, _without_ 
doing something that won't be possible in the (near) future. 

P.S.: This is my first attempt at modifying the kernel. If I ask something 
that is obvious, just point me where the documentation for that is, or to the 
thread where that has been already discussed.

Thanks,
Edwin

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/