lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070227133656.c452fbb4.akpm@linux-foundation.org>
Date:	Tue, 27 Feb 2007 13:36:56 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Stephen Hemminger <shemminger@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] udivdi3: 64 bit divide

> On Tue, 27 Feb 2007 13:18:40 -0800 Stephen Hemminger <shemminger@...ux-foundation.org> wrote:
> On Tue, 27 Feb 2007 12:24:37 -0800
> Andrew Morton <akpm@...ux-foundation.org> wrote:
> 
> > > On Mon, 26 Feb 2007 17:35:17 -0800 Stephen Hemminger <shemminger@...ux-foundation.org> wrote:
> > > The kernel already has several implmentations and usages of 64 by 64 
> > > bit divide.
> > > 
> > > Although it is significantly slower, there are places that need it so
> > > provide one generic version using scaling, and allow existing platform
> > > versions to continue.
> > 
> > The reason we implement 64/32 via do_div() is, for better or for worse, to
> > make people think before they use it.  And to make it stand out, and so
> > that we discover places that are using it by accident, where they could use
> > something cheaper.
> > 
> > However your implementation of the presumably even more expensive 64/64
> > allows us to do 64/64 with a plain old "/" operator.
> > 
> > If the do_div() philosophy is any good then we should surely repeat it for
> > 64/64, no?
> > 
> 
> Then we should pull the existing udivdi3 implementations?

Not much point really.  Some architectures have gone and done that, but x86
has not.  x86 has enough coverage for us to pick up most problems, and any
remaining problems are obviously in scruffy architectures which don't care
about performance ;)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ