All of lore.kernel.org
 help / color / mirror / Atom feed
From: george anzinger <george@mvista.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 2.5.63
Date: Tue, 25 Feb 2003 18:08:13 -0800	[thread overview]
Message-ID: <3E5C218D.7060004@mvista.com> (raw)
In-Reply-To: <20030224203046.A14425@infradead.org>

Christoph Hellwig wrote:
>>George Anzinger <george@mvista.com>:
>>  o POSIX clocks & timers
> 
> 
> Care to explain what  FOLD_NANO_SLEEP_INTO_CLOCK_NANO_SLEEP
> is supposed to do?  It's always defined in signal.h, so we can
> aswell get rid of it..

It is there in case some one might want nanosleep to NOT be folded 
into clock_nanosleep.  For a while this was a moving target and I got 
a bit paranoid  :)  I see no real reason to keep it...
> 
> And what's this:
> 
> #ifndef div_long_long_rem
> +#include <asm/div64.h>
> +
> +#define div_long_long_rem(dividend,divisor,remainder) ({ \
> +                      u64 result = dividend;           \
> +                      *remainder = do_div(result,divisor); \
> +                      result; })
> +
> +#endif                         /* ifndef div_long_long_rem */
> 
> Any reason you can't just use do_div directly like everyone else? :)

Actually I have coded a better function as part of the expanded 
high-res-timers which does a 64-bit/32-bit div in a much cleaner way. 
  Again, it is part of the full high-res-timers patch.  I have been 
thinking of submitting the complete set of these math routines outside 
of the high-res patch.  They are designed to make scaled math easy.  I 
  have both a generic and a i386 header file, but they still need a 
bit of testing.

The issue is getting around the C limitation of not being able to use 
the div and mpy instructions that take 64-bits/32-bits and return 2 
32-bit results and the mpy which takes 2 32-bit operands and returns a 
64-bit result.

For scaled operations, they also roll a shift into the mix in an 
efficient way (i.e. a small inline asm function).


-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml


  reply	other threads:[~2003-02-26  1:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-24 19:32 Linux 2.5.63 Linus Torvalds
2003-02-24 20:10 ` Christoph Hellwig
2003-02-24 20:30 ` Christoph Hellwig
2003-02-26  2:08   ` george anzinger [this message]
2003-02-24 22:11 ` Linux 2.5.63 [kernel BUG at drivers/net/tulip/de2104x.c:925!] Remco Post
2003-02-24 22:32 ` Linux 2.5.63 John Cherry
2003-02-25 13:15 ` 2.5.63: fore200e.c doesn't compile Adrian Bunk
2003-02-25 14:45   ` chas williams
     [not found]     ` <200302251453.h1PErvGi030679@locutus.cmf.nrl.navy.mil>
2003-02-25 15:44       ` Adrian Bunk
2003-02-25 14:09 ` Linux 2.5.63 - nfs mount fails Helge Hafting

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=3E5C218D.7060004@mvista.com \
    --to=george@mvista.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@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.