[6844] in linux-scsi channel archive
Re: ncr53c8xx hack I disagree _strongly_ with
daemon@ATHENA.MIT.EDU (Ingo Molnar)
Sun Jul 18 04:41:27 1999
Date: Sun, 18 Jul 1999 10:30:38 +0200 (CEST)
From: Ingo Molnar <mingo@chiara.csoma.elte.hu>
To: Gerard Roudier <groudier@club-internet.fr>
cc: Linux <linux-kernel@vger.rutgers.edu>, linux-scsi@vger.rutgers.edu
In-Reply-To: <Pine.LNX.3.95.990718091538.657A-100000@localhost>
On Sun, 18 Jul 1999, Gerard Roudier wrote:
> I just found the following change in the ncr53c8xx driver:
>
> + if (lp && time_before_eq(lp->tags_stime + 3*HZ, jiffies)) {
> - if (lp && lp->tags_stime + (3*HZ) <= jiffies) {
>
> I do prefer a known bug that such a _not_ needed ambiguous construct, for
> the reason that, each time the arguments of time_before_eq() are
> _unfortunately_ in the reverse order we just get the opposite effect.
[i did not do that change, but] i personally do not find it hard to read.
It's the same, standard two-argument operator thing we use in many other
cases, like memcpy():
operator(x,y) := x operator y
in the above case:
time_before_eq(x,y) == x time_before_eq y
ie. 'x is before or equal to y'. What we'd like to have is an overloaded
'<' and '==' operator for time-type - but it's not that hard in C via
using function-syntax either. Just like memcpy(x,y) is easier to read via
an overloaded assignment operator, but it's not that hard to not mess it
up in it's current form either.
> The constructs I would have accepted looks like the following, for
> example:
>
> Either,
> + if (lp && time_before_jiffies_eq(lp->tags_stime + 3*HZ)) {
> Or,
> + if (lp && not_in_the_future(lp->tags_stime + 3*HZ)) {
>
> (And define appropriate macros if needed)
i agree, such things makes it more readable. The two fundamental operators
are:
in_the_future()
now()
in_the_past(x) := !now(x) && !in_the_future(x)
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
