From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
To: dccp@vger.kernel.org
Subject: Re: [PATCH 2/9]: Query supported CCIDs
Date: Fri, 28 Sep 2007 18:21:50 +0000 [thread overview]
Message-ID: <20070928182150.GA23546@ghostprotocols.net> (raw)
In-Reply-To: <200709281630.17307@strip-the-willow>
Em Fri, Sep 28, 2007 at 04:30:17PM +0100, Gerrit Renker escreveu:
> [DCCP]: Query supported CCIDs
>
> This provides a data structure to record which CCIDs are locally supported
> and three accessor functions:
> - a test function for internal use which is used to validate CCID requests
> made by the user;
> - a copy function so that the list can be used for feature-negotiation;
> - documented getsockopt() support so that the user can query capabilities.
>
> The data structure is a table which is filled in at compile-time with the
> list of available CCIDs (which in turn depends on the Kconfig choices).
>
> Using the copy function for cloning the list of supported CCIDs is useful for
> feature negotiation, since the negotiation is now with the full list of available
> CCIDs (e.g. {2, 3}) instead of the default value {2}. This means negotiation will
> not fail if the peer requests to use CCID3 instead of CCID2.
>
> Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
> ---
> Documentation/networking/dccp.txt | 4 +++
> include/linux/dccp.h | 1
> net/dccp/ccid.c | 48 ++++++++++++++++++++++++++++++++++++++
> net/dccp/ccid.h | 5 +++
> net/dccp/feat.c | 4 +++
> net/dccp/proto.c | 2 +
> 6 files changed, 64 insertions(+)
>
> --- a/net/dccp/ccid.h
> +++ b/net/dccp/ccid.h
> @@ -80,6 +80,11 @@ static inline void *ccid_priv(const stru
> return (void *)ccid->ccid_priv;
> }
>
> +extern int ccid_get_default_ccids(u8 **ccid_array, u8 *array_len);
> +extern bool ccid_support_check(u8 const *ccid_array, u8 array_len);
> +extern int ccid_getsockopt_available_ccids(struct sock *sk, int len,
> + char __user *, int __user *);
> +
> extern struct ccid *ccid_new(unsigned char id, struct sock *sk, int rx,
> gfp_t gfp);
>
> --- a/net/dccp/ccid.c
> +++ b/net/dccp/ccid.c
> @@ -13,6 +13,13 @@
>
> #include "ccid.h"
>
> +static u8 builtin_ccids[] = {
> + DCCPC_CCID2, /* CCID2 is supported by default */
> +#if defined(CONFIG_IP_DCCP_CCID3) || defined(CONFIG_IP_DCCP_CCID3_MODULE)
> + DCCPC_CCID3,
> +#endif
> +};
This considers only code that was already merged. What about a new CCID
that is not yet merged? I guess the table should be managed at ccid
module registration time... but that would prevent autoloading on
demand, so I think that a sysctl interface that tells the DCCP core
infrastructure which are the ccids that are available is better.
Think also about an administrator deciding that even with the Linux
kernel provided by his vendor containing modules for ccid2, 3, etc, he
only accepts ccid3 or some other subset.
We could have as default a table built with the modules we know at dccp
core build time to be available in the current kernel build, but not
prevent others from being added or existing ones to be disabled.
So I think we can start with what you provided and implement my
suggestions later.
- Arnaldo
next prev parent reply other threads:[~2007-09-28 18:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-28 15:30 [PATCH 2/9]: Query supported CCIDs Gerrit Renker
2007-09-28 18:21 ` Arnaldo Carvalho de Melo [this message]
2007-09-29 16:24 ` Gerrit Renker
2007-09-29 17:58 ` Arnaldo Carvalho de Melo
2007-10-01 11:07 ` Gerrit Renker
2007-10-01 18:26 ` Ian McDonald
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070928182150.GA23546@ghostprotocols.net \
--to=acme@ghostprotocols.net \
--cc=dccp@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.