All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Fabio Olive Leite <fleite@redhat.com>
Cc: linux-nfs <nfs@lists.sourceforge.net>
Subject: Re: [PATCH] Attribute timeout handling and wrapping u32	jiffies
Date: Wed, 25 Jul 2007 10:32:59 -0400	[thread overview]
Message-ID: <1185373979.6585.81.camel@localhost> (raw)
In-Reply-To: <20070725142824.GA24321@sleipnir.redhat.com>

On Wed, 2007-07-25 at 11:28 -0300, Fabio Olive Leite wrote:
> On Wed, Jul 25, 2007 at 10:00:13AM -0400, Trond Myklebust wrote:
> > >  
> > > +#define timeout_or_wrap(a,b,c)	\
> > > +	(typecheck(unsigned long, a) && \
> > > +	 typecheck(unsigned long, b) && \
> > > +	 ((a) < (b) || (a) - (b) > (c)))
> > > +
> > 
> > Ugly name. Besides, the above macro causes problems at the wraparound
> > boundary when (b) may indeed be < (a), but we're still in the allowed
> > range. There is also no guarantee that (c) is unsigned. How about
> > 
> > #define time_in_range(a,b,c) \
> > 	(time_after_eq(a,b) && \
> > 	 time_before_eq(a,c))
> > 
> > instead?
> 
> Hmmm (a) is the "current" jiffies, (b) is the "stored" jiffies, and
> both are always unsigned long. But (c) is the timeout constant, and I
> thought better not to assume typing info there, as a small integer
> fits in many types.
> 
> I think that in the second check you mean this:
> 
> #define time_in_range(a,b,c) \
> 	(time_after_eq(a,b) && \
> 	 time_before_eq(a,b+c))

No. IMO [b;c] should be the range for the generic function, and it
should be up to the NFS code to do the 'stored jiffies + constant
timeout' calculation. You will note that time_in_range() does in any
case return true if you are inside the valid time range, so you will
usually want to do

if (!time_in_range())...

in order to do the timeout_or_wrap() test.

Trond


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2007-07-25 14:33 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-25  3:08 [PATCH] Attribute timeout handling and wrapping u32 jiffies Fabio Olive Leite
2007-07-25 14:00 ` Trond Myklebust
2007-07-25 14:28   ` Fabio Olive Leite
2007-07-25 14:32     ` Trond Myklebust [this message]
2007-07-25 14:54       ` Fabio Olive Leite
2007-07-27  1:59       ` Fabio Olive Leite
2007-07-31 16:25         ` Fabio Olive Leite
2007-07-31 19:47           ` Trond Myklebust
2007-08-22 18:25             ` Fabio Olive Leite
2007-08-22 18:47               ` J. Bruce Fields
2007-08-27 13:23               ` Trond Myklebust

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=1185373979.6585.81.camel@localhost \
    --to=trond.myklebust@fys.uio.no \
    --cc=fleite@redhat.com \
    --cc=nfs@lists.sourceforge.net \
    /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.