diff for duplicates of <48BCD945.1020009@cn.fujitsu.com> diff --git a/a/1.txt b/N1/1.txt index f74a858..d2829d7 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -4,7 +4,7 @@ Gerrit Renker wrote: > | > +{ > | > + switch (feat_num) { > | > + case DCCPF_CCID: -> | > + return val = DCCPC_CCID2 || val = DCCPC_CCID3; +> | > + return val == DCCPC_CCID2 || val == DCCPC_CCID3; > | > | Shouldn't we look at the registered CCIDs and do validation based on the > | modules loaded? Doing it this hardcoded way will prevent testing CCID4, @@ -64,14 +64,14 @@ u8 opt, ... { > if (ccid_get_builtin_ccids(&tx.val, &tx.len) || > ccid_get_builtin_ccids(&rx.val, &rx.len)) > return -ENOBUFS; -> => If it succeeds, the `tx' and `rx' entries will be identical copies. +> ==> If it succeeds, the `tx' and `rx' entries will be identical copies. > > 3. The next step in dccp_feat_init is to try and load all configured CCIDs: > > if (ccid_request_modules(tx.val, tx.len)) > goto free_ccid_lists; > -> => If this succeeds, the host is ready to answer to any request by +> ==> If this succeeds, the host is ready to answer to any request by > the peer. > > 4. Finally, if the peer tries to negotiate an unknown CCID, negotiation diff --git a/a/content_digest b/N1/content_digest index eecd315..7f150c3 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,8 +1,20 @@ + "ref\01219945512-7723-1-git-send-email-gerrit@erg.abdn.ac.uk\0" + "ref\01219945512-7723-2-git-send-email-gerrit@erg.abdn.ac.uk\0" + "ref\01219945512-7723-3-git-send-email-gerrit@erg.abdn.ac.uk\0" + "ref\01219945512-7723-4-git-send-email-gerrit@erg.abdn.ac.uk\0" + "ref\01219945512-7723-5-git-send-email-gerrit@erg.abdn.ac.uk\0" + "ref\01219945512-7723-6-git-send-email-gerrit@erg.abdn.ac.uk\0" + "ref\01219945512-7723-7-git-send-email-gerrit@erg.abdn.ac.uk\0" "ref\01219945512-7723-8-git-send-email-gerrit@erg.abdn.ac.uk\0" + "ref\020080828205447.GN9193@ghostprotocols.net\0" + "ref\020080829061237.GD3557@gerrit.erg.abdn.ac.uk\0" "From\0Wei Yongjun <yjwei@cn.fujitsu.com>\0" - "Subject\0Re: [PATCH 07/37] dccp: Registration routines for changing feature\0" - "Date\0Tue, 02 Sep 2008 06:12:21 +0000\0" - "To\0dccp@vger.kernel.org\0" + "Subject\0Re: [PATCH 07/37] dccp: Registration routines for changing feature values\0" + "Date\0Tue, 02 Sep 2008 14:12:21 +0800\0" + "To\0Gerrit Renker <gerrit@erg.abdn.ac.uk>" + Arnaldo Carvalho de Melo <acme@redhat.com> + dccp@vger.kernel.org + " netdev@vger.kernel.org\0" "\00:1\0" "b\0" "Gerrit Renker wrote:\n" @@ -11,7 +23,7 @@ "> | > +{\n" "> | > +\tswitch (feat_num) {\n" "> | > +\tcase DCCPF_CCID:\n" - "> | > +\t\treturn val = DCCPC_CCID2 || val = DCCPC_CCID3;\n" + "> | > +\t\treturn val == DCCPC_CCID2 || val == DCCPC_CCID3;\n" "> | \n" "> | Shouldn't we look at the registered CCIDs and do validation based on the\n" "> | modules loaded? Doing it this hardcoded way will prevent testing CCID4,\n" @@ -71,14 +83,14 @@ "> if (ccid_get_builtin_ccids(&tx.val, &tx.len) ||\n" "> ccid_get_builtin_ccids(&rx.val, &rx.len))\n" "> return -ENOBUFS;\n" - "> => If it succeeds, the `tx' and `rx' entries will be identical copies.\n" + "> ==> If it succeeds, the `tx' and `rx' entries will be identical copies.\n" ">\n" "> 3. The next step in dccp_feat_init is to try and load all configured CCIDs:\n" ">\n" "> if (ccid_request_modules(tx.val, tx.len))\n" "> goto free_ccid_lists;\n" ">\n" - "> => If this succeeds, the host is ready to answer to any request by\n" + "> ==> If this succeeds, the host is ready to answer to any request by\n" "> \tthe peer.\n" ">\n" "> 4. Finally, if the peer tries to negotiate an unknown CCID, negotiation\n" @@ -87,4 +99,4 @@ "> our list.\n" > -081ec3d6febcc291c5357e93065fcdc33e6cbabd9f1cb4edd7f42f17954a7f2e +c948712e00fdf318c515d4a9d1e11b510231ca18297dc9eb43fb88870ee2d7e1
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.