From: Steve Dickson <SteveD@redhat.com>
To: Kevin Coffman <kwc@citi.umich.edu>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH 2/3] Try to use kernel function to determine supported Kerberos enctypes.
Date: Thu, 15 Apr 2010 07:58:56 -0400 [thread overview]
Message-ID: <4BC6FF80.80506@RedHat.com> (raw)
In-Reply-To: <z2j4d569c331004141258y2f16a82ga1aa7826d665b3a9@mail.gmail.com>
Hey Kevin,
On 04/14/2010 03:58 PM, Kevin Coffman wrote:
>
> The global krb5_enctypes array was used when the list was being read
> once from a file. With the list now coming up with each request in
> the updated upcall, I think the list obtained in the upcall should be
> added to the clnt_info structure and then passed to the
> limit_krb5_enctypes function as a parameter.
I took a look at move the krb5_enctypes array in to the clnt_info structure
and I'm thinking it might be better to keep it as global variable.
Here is my reasoning...
The "enctypes=" string that comes up in the upcall is basically a
static string. Yeah I know it could change but that's highly unlikely
any time soon. So if we put the krb5_enctypes array in the clnt_info
structure we would have to parse that (static) string on *every* upcall,
since the clnt_info structures are dynamically allocated. So
parsing a static string on every upcall does not make sense to me.
Keeping the supported enctypes in a global variable allow us to
parse the string once and when it changes (which will never happen
dynamically). So if the first enctypes values are cached, all that
parsing become a simple strcmp()... ala:
+parse_enctypes(char *enctypes)
+{
+ int n = 0;
+ char *curr, *comma;
+ int i;
+ static char *cached_types;
+
+ if (cached_types && strcmp(cached_types, enctypes) == 0)
+ return 0;
Makes sense? Am I missing something??
steved.
next prev parent reply other threads:[~2010-04-15 11:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-14 19:18 [PATCH 0/3] nfs-utils: Adds support for more encryption types steved
2010-04-14 19:18 ` [PATCH 1/3] gssd: move function limit_krb5_enctypes into the exported functions area steved
2010-04-14 19:18 ` [PATCH 2/3] Try to use kernel function to determine supported Kerberos enctypes steved
2010-04-14 19:58 ` Kevin Coffman
[not found] ` <z2j4d569c331004141258y2f16a82ga1aa7826d665b3a9-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-04-14 20:05 ` Steve Dickson
2010-04-15 11:58 ` Steve Dickson [this message]
2010-04-15 13:25 ` Kevin Coffman
2010-04-15 12:45 ` [PATCH 2/3] Try to use kernel function to determine supported Kerberos enctypes (Updated) Steve Dickson
2010-04-14 19:18 ` [PATCH 3/3] Add support for non-DES encryption types steved
2010-04-16 17:53 ` [PATCH 0/3] nfs-utils: Adds support for more " Steve Dickson
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=4BC6FF80.80506@RedHat.com \
--to=steved@redhat.com \
--cc=kwc@citi.umich.edu \
--cc=linux-nfs@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.