Re: Getting the new RxRPC patches upstream

[David Howells]

David Miller <davem@xxxxxxxxxxxxx> wrote:

> Now that Herbert cleared up the crypto layer issues
> the only problem left is that there are generic changes
> in there which are not strictly networking but which
> your subsequent networking changes depend upon.
>
> This is a mess, and makes merging your work into the
> net-2.6.22 tree more difficult.

There are only two non-net patches that AF_RXRPC depends on:

 (1) The key facility changes.  That's all my code anyway, and shouldn't be a
     problem to merge unless someone else has put some changes in there that I
     don't know about.

 (2) try_to_cancel_delayed_work().  I suppose I could use
     cancel_delayed_work() instead, but that's less efficient as it waits for
     the timer completion function to finish.

And one that AFS depends on:

 (3) Cache the key in nameidata.  I still don't have Al's agreement on this,
     but it's purely caching, so I could drop that patch for the moment and
     excise the stuff that uses it from my AFS patches if that would help.

Do you class the AFS patches as "networking changes"?

Do you want me to consolidate my patches to make things simpler for you?

Do you want me to rebase my patches onto net-2.6.22?

I have the following patches, in order, available now, though I haven't yet
released the last few (they can all be downloaded from my RH people pages):

	move-skb-generic.diff  (you've got this)
	timers.diff
	keys.diff
	af_rxrpc.diff
	afs-cleanup.diff
	af_rxrpc-kernel.diff
	af_rxrpc-afs.diff
	af_rxrpc-delete-old.diff
	af_rxrpc-own-workqueues.diff
	af_rxrpc-fixes.diff
	afs-callback-wq.diff
	afs-vlocation.diff
	afs-multimount.diff
	afs-rxrpc-key.diff
	afs-nameidata-key.diff
	afs-security.diff
	afs-doc.diff
	netlink-support-MSG_TRUNC.diff  (you've got this)
	afs-get-capabilities.diff
	afs-initcallbackstate3.diff
	afs-dir-write-support.diff

David
-
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/