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

From: Török Edwin
Date: Sat Feb 18 2006 - 09:14:39 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/