linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Erik Andersen <andersen@codepoet.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Andrew Morton <akpm@osdl.org>,
	"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
	linux-kernel@vger.kernel.org, jun.nakajima@intel.com
Subject: Re: [PATCHSET][2.6-test4][0/6]Support for HPET based timer - Take 2
Date: Sun, 31 Aug 2003 16:24:14 -0600	[thread overview]
Message-ID: <20030831222414.GA29923@codepoet.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0308311404430.1581-100000@home.osdl.org>

On Sun Aug 31, 2003 at 02:05:25PM -0700, Linus Torvalds wrote:
> 
> On Fri, 29 Aug 2003, Erik Andersen wrote:
> > 
> > gcc then generates code calling __udivdi3 and __umoddi3.  Since
> > the kernel does not provide these, people keep reinventing them.
> > Perhaps it is time to kill off do_div and all its little friends
> > and simply copy __udivdi3 and __umoddi3 from libgcc.....
> 
> No. do_div() does _nothing_ like __udivdi3/__umoddi3.
> 
> Read the documentation.

Been there done that, got the scars to prove it.  do_div() is a
macro that acts sortof like the ISO C99 lldiv(3) function.
Except it does unexpected things like modify its arguments... 

Most places in the kernel using do_div() not because it is the
right thing to do, but because they tried to do something
seemingly simple such as:

    u64 foo, bar, baz;
    ...
    baz = foo / bar;

and then got an error that __udivdi3 was undefined.  So the
authors then go hunting for a way to do a 64 bit division and
find do_div()...

See mm/vmscan.c, mm/shmem.c, fs/proc/proc_misc.c,
drivers/ide/ide-disk.c, etc, etc, etc, for plenty of examples of
_exactly_ this sort of thing.  Every one of them is using
do_div() to perform 64 bit division.  Not becase that is the
right thing to do, but because __udivdi3 is missing.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

  reply	other threads:[~2003-08-31 22:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-28 23:41 [PATCHSET][2.6-test4][0/6]Support for HPET based timer - Take 2 Pallipadi, Venkatesh
2003-08-29 18:23 ` Andrew Morton
2003-08-29 21:03   ` Erik Andersen
2003-08-31 21:05     ` Linus Torvalds
2003-08-31 22:24       ` Erik Andersen [this message]
2003-08-31 22:48         ` Linus Torvalds
2003-09-05 22:19     ` George Anzinger
     [not found] <pEGJ.73p.5@gated-at.bofh.it>
2003-08-29  3:40 ` David Mosberger-Tang
2003-08-29 16:12 Pallipadi, Venkatesh
2003-08-30  4:59 ` David Mosberger-Tang
2003-08-29 23:58 Pallipadi, Venkatesh
2003-09-05 22:26 ` George Anzinger
2003-08-30 16:26 Pallipadi, Venkatesh
2003-09-06 19:04 Pallipadi, Venkatesh
2003-09-07 17:57 ` George Anzinger

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=20030831222414.GA29923@codepoet.org \
    --to=andersen@codepoet.org \
    --cc=akpm@osdl.org \
    --cc=jun.nakajima@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    --cc=venkatesh.pallipadi@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).