* Re: Git-commits mailing list feed.
From: Linus Torvalds @ 2005-04-23 18:30 UTC (permalink / raw)
To: Thomas Glanzmann
Cc: David Woodhouse, Jan Dittmer, Greg KH, Kernel Mailing List,
Git Mailing List
In-Reply-To: <20050423175422.GA7100@cip.informatik.uni-erlangen.de>
On Sat, 23 Apr 2005, Thomas Glanzmann wrote:
>
> # This creates the signature.
> gpg --clearsign < sign_this > signature
This really doesn't work for me - I do not want to have the gpg header
above it, only the signature below. Since I want git to actually
understand the tags, but do _not_ want git to have to know about whatever
signing method was used, I really want the resulting file to look like
commit ....
tag ...
here goes comment
here goes signature
and no headers.
Whether that can be faked by always forcing SHA1 as the hash, and then
just removing the top lines, and re-inserting them when verifying, or
whether there is some mode to make gpg not do the header crud at all, I
don't know. Which is exactly why I never even got started.
Linus
^ permalink raw reply
* [PATCH] Add -i option to cat-file to allow operation on displaced git object files
From: Jon Seymour @ 2005-04-23 18:27 UTC (permalink / raw)
To: Git Mailing List
For the purposes of merging the contents of remote git object
repositories at the filesystem level, it would be helpful to be able
to verify the integrity of a remote git object file before it is
actually copied into the local repository.
To enable this, the option syntax for the usage of the cat-file tool
is extended with a -i option, per the modified usage string quoted
below:
usage: cat-file [-t | tagname] <sha1> [ -i displaced-git-object-file ]
If the -i option is specified, cat-file uses the filename specified on
the command line rather than the derived filename to locate and
process the git object file implied by the sha1 argument.
In addition, the -i option forces cat-file to check the SHA1 signature
of the specified input file against the SHA1 signature specified on
the command line and report an error if there is a mismatch.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
--
Index: cache.h
===================================================================
--- e6d3a81c30ad237102e2ca82f3dfc57d0b9f0ddf/cache.h (mode:100644
sha1:bf30ac4741d2eeeb483079f566182505898082f3)
+++ 1b503f0571727a865b413e28641d2be09c8c3304/cache.h (mode:100644
sha1:56eacfa0ab43c93a838efedca429e865c95f16bc)
@@ -121,8 +121,9 @@
extern void * map_sha1_file(const unsigned char *sha1, unsigned long *size);
extern void * unpack_sha1_file(void *map, unsigned long mapsize,
char *type, unsigned long *size);
extern void * read_sha1_file(const unsigned char *sha1, char *type,
unsigned long *size);
+extern void * read_displaced_sha1_file(char *type, unsigned long
*size, const char *filename);
extern int write_sha1_file(char *buf, unsigned len, unsigned char
*return_sha1);
-extern int check_sha1_signature(unsigned char *sha1, void *buf,
unsigned long size, const char *type);
+extern int check_sha1_signature(const unsigned char *sha1, void *buf,
unsigned long size, const char *type);
/* Read a tree into the cache */
extern int read_tree(void *buffer, unsigned long size, int stage);
Index: cat-file.c
===================================================================
--- e6d3a81c30ad237102e2ca82f3dfc57d0b9f0ddf/cat-file.c (mode:100644
sha1:3c47d79a16305d326a65768fe9f37ee25928510b)
+++ 1b503f0571727a865b413e28641d2be09c8c3304/cat-file.c (mode:100644
sha1:c88df7287b6ce7d6d33d016ffb524cc5a793cad2)
@@ -5,16 +5,32 @@
*/
#include "cache.h"
+static char _usage[]="cat-file [-t | tagname] <sha1> [ -i
displaced-git-object-file ]";
+
int main(int argc, char **argv)
{
unsigned char sha1[20];
char type[20];
- void *buf;
+ void *buf = NULL;
unsigned long size;
- if (argc != 3 || get_sha1_hex(argv[2], sha1))
- usage("cat-file [-t | tagname] <sha1>");
- buf = read_sha1_file(sha1, type, &size);
+ if (argc < 3 || get_sha1_hex(argv[2], sha1))
+ usage(_usage);
+
+ if (argc == 3) {
+ buf = read_sha1_file(sha1, type, &size);
+ } else if (argc == 5 && !strcmp(argv[3], "-i")) {
+ buf = read_displaced_sha1_file(type, &size, argv[4]);
+ if (!buf)
+ die("bad file: %s", argv[4]);
+
+ if (check_sha1_signature(sha1, buf, size, type) < 0)
+ die("signature mismatch for %s", argv[4]);
+
+ } else {
+ usage(_usage);
+ }
+
if (!buf)
die("cat-file %s: bad file", argv[2]);
if (!strcmp("-t", argv[1])) {
Index: sha1_file.c
===================================================================
--- e6d3a81c30ad237102e2ca82f3dfc57d0b9f0ddf/sha1_file.c (mode:100644
sha1:6f7228e106d4e24b18f8416cc6adc2a6fd303eb7)
+++ 1b503f0571727a865b413e28641d2be09c8c3304/sha1_file.c (mode:100644
sha1:25e2e8b22cf9590a6df05f234ce88db8c2cd1030)
@@ -80,7 +80,7 @@
return base;
}
-int check_sha1_signature(unsigned char *sha1, void *map, unsigned
long size, const char *type)
+int check_sha1_signature(const unsigned char *sha1, void *map,
unsigned long size, const char *type)
{
char header[100];
unsigned char real_sha1[20];
@@ -93,13 +93,12 @@
return memcmp(sha1, real_sha1, 20) ? -1 : 0;
}
-void *map_sha1_file(const unsigned char *sha1, unsigned long *size)
+static void *map_file(const char *filename, unsigned long *size)
{
- char *filename = sha1_file_name(sha1);
- int fd = open(filename, O_RDONLY);
struct stat st;
void *map;
+ int fd = open(filename, O_RDONLY);
if (fd < 0) {
perror(filename);
return NULL;
@@ -116,6 +115,12 @@
return map;
}
+void *map_sha1_file(const unsigned char *sha1, unsigned long *size)
+{
+ char *filename = sha1_file_name(sha1);
+ return map_file(filename, size);
+}
+
void * unpack_sha1_file(void *map, unsigned long mapsize, char
*type, unsigned long *size)
{
int ret, bytes;
@@ -166,6 +171,20 @@
return NULL;
}
+void * read_displaced_sha1_file(char *type, unsigned long *size,
const char *filename)
+{
+ unsigned long mapsize;
+ void *map, *buf;
+
+ map = map_file(filename, &mapsize);
+ if (map) {
+ buf = unpack_sha1_file(map, mapsize, type, size);
+ munmap(map, mapsize);
+ return buf;
+ }
+ return NULL;
+}
+
void *read_tree_with_tree_or_commit_sha1(const unsigned char *sha1,
unsigned long *size,
unsigned char *tree_sha1_return)
^ permalink raw reply
* [PATCH] make file merging respect permissions
From: James Bottomley @ 2005-04-23 18:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
I noticed when playing about with merging that executable scripts lose
their permissions after a merge. This was because unpack-file just
unpacks to whatever the current umask is.
I also noticed that the merge-one-file-script thinks that if the file
has been removed in both branches, then it should simply be removed.
This isn't correct. The file could have been renamed to something
different in both branches, in which case we have an unflagged rename
conflict.
The attached fixes both issues
James
--- a/git-merge-one-file-script
+++ b/git-merge-one-file-script
@@ -20,23 +20,47 @@ mkdir -p "$dir"
case "${1:-.}${2:-.}${3:-.}" in
#
-# deleted in both, or deleted in one and unchanged in the other
+# deleted in both
+#
+"$1..")
+ echo "ERROR: $4 is removed in both branches"
+ echo "ERROR: This is a potential rename conflict"
+ exit 1;;
+#
+# deleted in one and unchanged in the other
#
"$1.." | "$1.$1" | "$1$1.")
rm -f -- "$4"
+ echo "Removing $4"
update-cache --remove -- "$4"
exit 0
;;
#
-# added in one, or added identically in both
+# added in one
#
-".$2." | "..$3" | ".$2$2")
- mv $(unpack-file "${2:-$3}") $4
+".$2." | "..$3" )
+ echo "Adding $4 with perm $6$7"
+ mv $(unpack-file "$2$3") $4
+ chmod "$6$7" $4
update-cache --add -- $4
exit 0
;;
-
+#
+# Added in both (check for same permissions)
+#
+".$2$2")
+ if [ "$6" != "$7" ]; then
+ echo "ERROR:"
+ echo "ERROR: File $4 added in both branches, permissions conflict $6->$7"
+ echo "ERROR:"
+ exit 1
+ fi
+ echo "Adding $4 with perm $6"
+ mv $(unpack-file "$2") $4
+ chmod "$6" $4
+ update-cache --add -- $4
+ exit 0;;
#
# Modified in both, but differently ;(
#
@@ -46,12 +70,21 @@ case "${1:-.}${2:-.}${3:-.}" in
src1=$(unpack-file $2)
src2=$(unpack-file $3)
merge "$src2" "$orig" "$src1"
- if [ $? -ne 0 ]; then
- echo Leaving conflict merge in $src2
+ ret=$?
+ if [ "$6" != "$7" ]; then
+ echo "ERROR: Permissions $5->$6->$7" don't match merging $src2"
+ if [ $ret -ne 0 ]; then
+ echo "ERROR: Leaving conflict merge in $src2"
+ fi
+ exit 1
+ fi
+ chmod -- "$6" "$src2"
+ if [ $ -ne 0 ]; then
+ echo "ERROR: Leaving conflict merge in $src2"
exit 1
fi
- cp "$src2" "$4" && update-cache --add -- "$4" && exit 0
+ cp -- "$src2" "$4" && chmod -- "$6" "$4" && update-cache --add -- "$4" && exit 0
;;
*)
--- a/merge-cache.c
+++ b/merge-cache.c
@@ -4,7 +4,7 @@
#include "cache.h"
static const char *pgm = NULL;
-static const char *arguments[5];
+static const char *arguments[8];
static void run_program(void)
{
@@ -18,6 +18,9 @@ static void run_program(void)
arguments[2],
arguments[3],
arguments[4],
+ arguments[5],
+ arguments[6],
+ arguments[7],
NULL);
die("unable to execute '%s'", pgm);
}
@@ -36,9 +39,13 @@ static int merge_entry(int pos, const ch
arguments[2] = "";
arguments[3] = "";
arguments[4] = path;
+ arguments[5] = "";
+ arguments[6] = "";
+ arguments[7] = "";
found = 0;
do {
static char hexbuf[4][60];
+ static char ownbuf[4][60];
struct cache_entry *ce = active_cache[pos];
int stage = ce_stage(ce);
@@ -46,7 +53,9 @@ static int merge_entry(int pos, const ch
break;
found++;
strcpy(hexbuf[stage], sha1_to_hex(ce->sha1));
+ sprintf(ownbuf[stage], "%o", ntohl(ce->ce_mode) & (~S_IFMT));
arguments[stage] = hexbuf[stage];
+ arguments[stage + 4] = ownbuf[stage];
} while (++pos < active_nr);
if (!found)
die("merge-cache: %s not in the cache", path);
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Thomas Glanzmann @ 2005-04-23 17:54 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Woodhouse, Jan Dittmer, Greg KH, Kernel Mailing List,
Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504231010580.2344@ppc970.osdl.org>
Hello,
there is no need to tell the verifier against what key to verify because
the signature already contains this information.
> If somebody writes a script to generate the above kind of thing (and
> tells me how to validate it), I'll do the rest, and start tagging
> things properly. Oh, and make sure the above sounds sane (ie if
> somebody has a better idea for how to more easily identify how to find
> the public key to check against, please speak up).
# This creates the signature.
gpg --clearsign < sign_this > signature
# And this verifies it.
gpg --verify < signature && echo valid
Thomas
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Fabian Franz @ 2005-04-23 17:50 UTC (permalink / raw)
To: Linus Torvalds, David Woodhouse
Cc: Jan Dittmer, Greg KH, Kernel Mailing List, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504231010580.2344@ppc970.osdl.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am Samstag, 23. April 2005 19:31 schrieb Linus Torvalds:
> On Sun, 24 Apr 2005, David Woodhouse wrote:
> > Nah, asking Linus to tag his releases is the most comfortable way.
> >
> The reason I've not done tags yet is that I haven't decided how to do
> them.
>
> commit a2755a80f40e5794ddc20e00f781af9d6320fafb
> tag v2.6.12-rc3
> signer Linus Torvalds
>
> This is my official original 2.6.12-rc2 release
>
> -----BEGIN PGP SIGNATURE-----
> ....
> -----END PGP SIGNATURE-----
>
> If somebody writes a script to generate the above kind of thing (and tells
> me how to validate it), I'll do the rest, and start tagging things
> properly. Oh, and make sure the above sounds sane (ie if somebody has a
> better idea for how to more easily identify how to find the public key to
> check against, please speak up).
To generate those you do:
# cat unsigned_tag
commit a2755a80f40e5794ddc20e00f781af9d6320fafb
tag v2.6.12-rc3
signer Linus Torvalds
This is my official original 2.6.12-rc2 release
# gpg --clearsign < unsigned_tag > signed_tag # gpg will ask here for the
secret key phrase
To verify you do:
# gpg --verify < signed_tag
and check exit status.
Hope that helps,
cu
Fabian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCaorzI0lSH7CXz7MRAr3QAJ45f2CQTgJ0sYfF9kRyrWHbsazVQQCeMqW7
HCsah/llt/I8sQ36dlDnRWg=
=Fgq1
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Linus Torvalds @ 2005-04-23 17:45 UTC (permalink / raw)
To: David Woodhouse
Cc: Jan Dittmer, Greg KH, Kernel Mailing List, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504231010580.2344@ppc970.osdl.org>
On Sat, 23 Apr 2005, Linus Torvalds wrote:
>
> commit a2755a80f40e5794ddc20e00f781af9d6320fafb
> tag v2.6.12-rc3
> signer Linus Torvalds
>
> This is my official original 2.6.12-rc2 release
>
> -----BEGIN PGP SIGNATURE-----
> ....
> -----END PGP SIGNATURE-----
Btw, in case it wasn't clear, one of the advantages of this is that these
objects are really _not_ versioned themselves, and that they are totally
independent of the objects that they actually tag.
They spread together with all the other objects, so they fit very well
into the whole git infrastructure, but the real commit objects don't have
any linkages to the tag and the tag objects themselves don't have any
history amongst themselves, so you can create a tag at any (later) time,
and it doesn't actually change the commit in any way or affect other tags
in any way.
In particular, many different people can tag the same commit, and they
don't even need to tage their _own_ commit - you can use this tag objects
to show that you trust somebody elses commit. You can also throw the tag
objects away, since nothing else depends on them and they have nothing
linking to them - so you can make a "one-time" tag object that you can
pass off to somebody else, and then delete it, and now it's just a
"temporary tag" that tells the recipient _something_ about the commit you
tagged, but that doesn't stay around in the archive.
That's important, because I actually want to have the ability for people
who want me to pull from their archive to send me a message that says
"pull from this archive, and btw, here's the tag that not only tells you
which head to merge, but also proves that it was me who created it".
Will we use this? Maybe not. Quite frankly, I think human trust is much
more important than automated trust through some technical means, but I
think it's good to have the _support_ for this kind of trust mechanism
built into the system. And I think it's a good way for distributors etc to
say: "this is the source code we used to build the kernel that we
released, and we tagged it 'v2.6.11-mm6-crazy-fixes-3.96'".
And if my key gets stolen, I can re-generate all the tags (from my archive
of tags that I trust), and sign them with a new key, and revoke the trust
of my old key. This is why it's important that tags don't have
interdependencies, they are just a one-way "this key trusts that release
and calls it xyzzy".
Linus
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Linus Torvalds @ 2005-04-23 17:31 UTC (permalink / raw)
To: David Woodhouse
Cc: Jan Dittmer, Greg KH, Kernel Mailing List, Git Mailing List
In-Reply-To: <1114266907.3419.43.camel@localhost.localdomain>
On Sun, 24 Apr 2005, David Woodhouse wrote:
>
> Nah, asking Linus to tag his releases is the most comfortable way.
>
> mkdir .git/tags
> echo 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 > .git/tags/2.6.12-rc2
> echo a2755a80f40e5794ddc20e00f781af9d6320fafb > .git/tags/2.6.12-rc3
The reason I've not done tags yet is that I haven't decided how to do
them.
The git-pasky "just remember the tag name" approach certainly works, but I
was literally thinking o fsetting up some signing system, so that a tag
doesn't just say "commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 is
v2.6.12-rc2", but it would actually give stronger guarantees, ie it would
say "Linus says that commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 is
his 2.6.12-rc2 release".
That's something fundamentally more powerful, and it's also something that
I actually can integrate better into git.
In other words, I actually want to create "tag objects", the same way we
have "commit objects". A tag object points to a commit object, but in
addition it contains the tag name _and_ the digital signature of whoever
created the tag.
Then you just distribute these tag objects along with all the other
objects, and fsck-cache can pick them up even without any other knowledge,
but normally you'd actually point to them some other way too, ie you could
have the ".git/tags/xxx" files have the pointers, but now they are
_validated_ pointers.
That was my plan, at least. But I haven't set up any signature generation
thing, and this really isn't my area of expertise any more. But my _plan_
literally was to have the tag object look a lot like a commit object, but
instead of pointing to the tree and the commit parents, it would point to
the commit you are tagging. Somehting like
commit a2755a80f40e5794ddc20e00f781af9d6320fafb
tag v2.6.12-rc3
signer Linus Torvalds
This is my official original 2.6.12-rc2 release
-----BEGIN PGP SIGNATURE-----
....
-----END PGP SIGNATURE-----
with a few fixed headers and then a place for free-form commentary,
everything signed by the key (and then it ends up being encapsulated as an
object with the object type "tag", and SHA1-csummed and compressed, ie it
ends up being just another object as far as git is concerned, but now it's
an object that tells you about _trust_)
(The "signer" field is just a way to easily figure out which public key to
check the signature against, so that you don't have to try them all. Or
something. My point being that I know what I want, but because I normally
don't actually ever _use_ PGP etc, I don't know the scripts to create
these, so I've been punting on it all).
If somebody writes a script to generate the above kind of thing (and tells
me how to validate it), I'll do the rest, and start tagging things
properly. Oh, and make sure the above sounds sane (ie if somebody has a
better idea for how to more easily identify how to find the public key to
check against, please speak up).
Linus
^ permalink raw reply
* Re: Catching up: git-pasky-0.6.2 broken?
From: Martin Schlemmer @ 2005-04-23 16:19 UTC (permalink / raw)
To: Russell King; +Cc: git
In-Reply-To: <20050423152102.D32116@flint.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]
On Sat, 2005-04-23 at 15:21 +0100, Russell King wrote:
> On Sat, Apr 23, 2005 at 03:12:39PM +0100, Russell King wrote:
> > On Sat, Apr 23, 2005 at 12:47:58PM +0100, Russell King wrote:
> > > Any ideas what's going on?
> >
> > Could the problem be related to some random garbage left in .git/add-queue
> > and .git/rm-queue?
> >
> > If so, how did these files get generated in the first place, and why
> > weren't they removed when they were finished with?
> >
> > IMHO updating a repository from an external source should _NOT_ be
> > affected by the presence (or absense) of these two files, which
> > contain only _local_ state information.
>
> Ok, don't bother looking into this - I'm now completely git-free here.
> I think I'll prefer to use the old diff and patch method to submit
> stuff to Linus, until git has progressed sufficiently such that it
> doesn't end up wasting hours of my time.
>
> Yes, it's a radical solution, but since I _can't_ get it to work for
> me, it's the only one which will allow me to get any real work done.
>
> (and it all looked soo promising pre-0.6.2)
>
You did try 0.6.3? Think it fixed some annoying bugs. Also pull and
reinstall it to make sure one or two others might be fixed.
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Catching up: git-pasky-0.6.2 broken?
From: Russell King @ 2005-04-23 14:21 UTC (permalink / raw)
To: git
In-Reply-To: <20050423151238.C32116@flint.arm.linux.org.uk>
On Sat, Apr 23, 2005 at 03:12:39PM +0100, Russell King wrote:
> On Sat, Apr 23, 2005 at 12:47:58PM +0100, Russell King wrote:
> > Any ideas what's going on?
>
> Could the problem be related to some random garbage left in .git/add-queue
> and .git/rm-queue?
>
> If so, how did these files get generated in the first place, and why
> weren't they removed when they were finished with?
>
> IMHO updating a repository from an external source should _NOT_ be
> affected by the presence (or absense) of these two files, which
> contain only _local_ state information.
Ok, don't bother looking into this - I'm now completely git-free here.
I think I'll prefer to use the old diff and patch method to submit
stuff to Linus, until git has progressed sufficiently such that it
doesn't end up wasting hours of my time.
Yes, it's a radical solution, but since I _can't_ get it to work for
me, it's the only one which will allow me to get any real work done.
(and it all looked soo promising pre-0.6.2)
--
Russell King
^ permalink raw reply
* Re: Catching up: git-pasky-0.6.2 broken?
From: Russell King @ 2005-04-23 14:12 UTC (permalink / raw)
To: git
In-Reply-To: <20050423124758.B32116@flint.arm.linux.org.uk>
On Sat, Apr 23, 2005 at 12:47:58PM +0100, Russell King wrote:
> I've been away from git stuff since about Wednesday due to eye problems.
> Yesterday and today, I've been trying to catch up, but I'm running into
> problems.
>
> I grabbed git-pasky-0.6.2, and followed Linus' message about converting
> repositories. I've updated all the "heads", and cleaned out all the old
> sha1 files. After updating, I did a read-tree for the tracked head,
> followed by checkout-cache -f -a and update-cache --refresh.
>
> Therefore, in theory, everything should be in sync.
>
> However, git pull now has nasty side effects. At first I thought this
> was down to something still being out of sync. However, on the second
> pull, it's still producing the same complaints.
>
> It's almost although git has a single patch file subversely written into
> it to apply lpfc and qla changes which it's trying to apply irrespective
> of the objects downloaded.
>
> Any ideas what's going on?
Could the problem be related to some random garbage left in .git/add-queue
and .git/rm-queue?
If so, how did these files get generated in the first place, and why
weren't they removed when they were finished with?
IMHO updating a repository from an external source should _NOT_ be
affected by the presence (or absense) of these two files, which
contain only _local_ state information.
--
Russell King
^ permalink raw reply
* Re: [PATCH] PPC assembly implementation of SHA1
From: linux @ 2005-04-23 13:03 UTC (permalink / raw)
To: paulus; +Cc: git, linux
In-Reply-To: <20050423124246.30071.qmail@science.horizon.com>
One bug I spotted too late: the first line of the STEPD2
macro still references %r15; that should be the new home of k, %r5.
Sorry about that.
^ permalink raw reply
* Re: [PATCH] PPC assembly implementation of SHA1
From: linux @ 2005-04-23 12:42 UTC (permalink / raw)
To: paulus; +Cc: git, linux
I was working on the same thing, but hindered by lack of access to PPC
hardware. I notice that you also took advantage of the unaligned load
support and native byte order to do the hash straight from the source.
But I came up with a few additional refinements:
- You are using three temporaries (%r0, %r6, and RT(x)) for your
round functions. You only need one temporary (%r0) for all the functions.
(Plus %r15 for k)
The core round function is
e += (a <<< 5) + f(b,c,d) + W[i] + K
b = (b <<< 30)
followed by renaming the registers for the next round:
d += (e <<< 5) + f(a,b,c) + W[i+1] + K
a = (a <<< 30)
That can all be computed with one temporary.
There are three possible f() functions:
f1(x,y,z) = "bitwise x ? y : z"
= (x & y) | (~x & z)
= (x & y) + (~x & z)
= z ^ (x & (y ^ z))
All are three logical instrunctions on PPC. The second form
lets you add it into the accumulator e in two pieces:
+#define STEPD0(t) \
+ add %r0,%r15,W(t); \
+ add RE(t),RE(t),%r0; \
+ and %r0,RC(t),RB(t); \
+ add RE(t),RE(t),%r0; \
+ andc %r0,RD(t),RB(t); \
+ add RE(t),RE(t),%r0; \
+ rotlwi %r0,RA(t),5; \
+ rotlwi RB(t),RB(t),30; \
+ add RE(t),RE(t),%r0;
The XOR version f2(x,y,z) = x^y^z is of course trivial:
+#define STEPD1(t) \
+ add %r0,%r15,W(t); \
+ add RE(t),RE(t),%r0; \
+ xor %r0,RC(t),RB(t); \
+ xor %r0,%r0,RA(t); \
+ add RE(t),RE(t),%r0; \
+ rotlwi %r0,RA(t),5; \
+ rotlwi RB(t),RB(t),30; \
+ add RE(t),RE(t),%r0;
And the last function, majority(x,y,z), can be written as:
f3(x,y,z) = (x & y) | (y & z) | (z & x)
= (x & y) | z & (x | y)
= (x & y) | z & (x ^ y)
= (x & y) + z & (x ^ y)
The last form again allows evaluation with one temporary and
two adds into RE(t):
+#define STEPD2(t) \
+ add %r0,%r15,W(t); \
+ add RE(t),RE(t),%r0; \
+ and %r0,RC(t),RB(t); \
+ add RE(t),RE(t),%r0; \
+ xor %r0,RC(t),RB(t); \
+ and %r0,%r0,RA(t); \
+ add RE(t),RE(t),%r0; \
+ rotlwi %r0,RA(t),5; \
+ rotlwi RB(t),RB(t),30; \
+ add RE(t),RE(t),%r0;
Other notes:
- You don't need to decrement %r1 before saving registers.
The PPC calling convention defines a "red zone" below the
current stack pointer that is guaranteed never to be touched
by signal handlers or the like. This is specifically for
leaf procedure optimization, and is at least 224 bytes.
- Is that many stw/lwz instructions faster than stmw/lmw?
The latter is at least more cahce-friendly.
- You can avoid saving and restoring %r15 by recycling %r5 for that
purpose; it's not used after the mtctr %r5.
- (Note, by the way, that while the PPC supports unaligned loads, using
lmw to load unaligned data is SLOW onthe G5; multiple lwz instructions
are faster in that case.)
- The above changes actually save enough registers to cache the whole hash[5]
in registers as well, eliminating *all* unnecessary load/store traffic.
With all of the above changes, your sha1ppc.S file turns into:
diff -urN git.orig/ppc/sha1ppc.S git/ppc/sha1ppc.S
--- /dev/null 2005-04-04 12:56:19.000000000 +1000
+++ git/ppc/sha1ppc.S 2005-04-22 16:29:19.000000000 +1000
@@ -0,0 +1,142 @@
+/*
+ * SHA-1 implementation for PowerPC.
+ *
+ * Copyright (C) 2005 Paul Mackerras <paulus@samba.org>
+ */
+
+/*
+ * We roll the registers for A, B, C, D, E around on each
+ * iteration; A on iteration t is B on iteration t+1, and so on.
+ * We use registers 6 - 10 for this. (Registers 27 - 31 hold
+ * the previous values.)
+ */
+#define RA(t) ((((t)+4)%5)+6)
+#define RB(t) ((((t)+3)%5)+6)
+#define RC(t) ((((t)+2)%5)+6)
+#define RD(t) ((((t)+1)%5)+6)
+#define RE(t) ((((t)+0)%5)+6)
+
+/* We use registers 11 - 26 for the W values */
+#define W(t) (((t)%16)+11)
+
+#define STEPD0(t) \
+ add %r0,%r5,W(t); \
+ add RE(t),RE(t),%r0; \
+ and %r0,RC(t),RB(t); \
+ add RE(t),RE(t),%r0; \
+ andc %r0,RD(t),RB(t); \
+ add RE(t),RE(t),%r0; \
+ rotlwi %r0,RA(t),5; \
+ rotlwi RB(t),RB(t),30; \
+ add RE(t),RE(t),%r0;
+
+#define STEPD1(t) \
+ add %r0,%r5,W(t); \
+ add RE(t),RE(t),%r0; \
+ xor %r0,RC(t),RB(t); \
+ xor %r0,%r0,RA(t); \
+ add RE(t),RE(t),%r0; \
+ rotlwi %r0,RA(t),5; \
+ rotlwi RB(t),RB(t),30; \
+ add RE(t),RE(t),%r0;
+
+#define STEPD2(t) \
+ add %r0,%r15,W(t); \
+ add RE(t),RE(t),%r0; \
+ and %r0,RC(t),RB(t); \
+ add RE(t),RE(t),%r0; \
+ xor %r0,RC(t),RB(t); \
+ and %r0,%r0,RA(t); \
+ add RE(t),RE(t),%r0; \
+ rotlwi %r0,RA(t),5; \
+ rotlwi RB(t),RB(t),30; \
+ add RE(t),RE(t),%r0;
+
+#define LOADW(t) \
+ lwz W(t),(t)*4(%r4)
+
+#define UPDATEW(t) \
+ xor %r0,W((t)-3),W((t)-8); \
+ xor W(t),W((t)-16),W((t)-14); \
+ xor W(t),W(t),%r0; \
+ rotlwi W(t),W(t),1
+
+#define STEP0LD4(t) \
+ STEPD0(t); LOADW((t)+4); \
+ STEPD0((t)+1); LOADW((t)+5); \
+ STEPD0((t)+2); LOADW((t)+6); \
+ STEPD0((t)+3); LOADW((t)+7)
+
+#define STEPUP4(t, fn) \
+ STEP##fn(t); UPDATEW((t)+4); \
+ STEP##fn((t)+1); UPDATEW((t)+5); \
+ STEP##fn((t)+2); UPDATEW((t)+6); \
+ STEP##fn((t)+3); UPDATEW((t)+7)
+
+#define STEPUP20(t, fn) \
+ STEPUP4(t, fn); \
+ STEPUP4((t)+4, fn); \
+ STEPUP4((t)+8, fn); \
+ STEPUP4((t)+12, fn); \
+ STEPUP4((t)+16, fn)
+
+ .globl sha1_core
+sha1_core:
+ stmw %r13,-76(%r1)
+
+ /* Load up A - E */
+ lmw %r27,0(%r3)
+
+ mtctr %r5
+
+1: mr RA(0),%r27
+ LOADW(0)
+ mr RB(0),%r28
+ LOADW(1)
+ mr RC(0),%r29
+ LOADW(2)
+ mr RD(0),%r30
+ LOADW(3)
+ mr RE(0),%r31
+
+ lis %r5,0x5a82 /* K0-19 */
+ ori %r5,%r5,0x7999
+ STEP0LD4(0)
+ STEP0LD4(4)
+ STEP0LD4(8)
+ STEPUP4(12, D0)
+ STEPUP4(16, D0)
+
+ lis %r5,0x6ed9 /* K20-39 */
+ ori %r5,%r5,0xeba1
+ STEPUP20(20, D1)
+
+ lis %r5,0x8f1b /* K40-59 */
+ ori %r5,%r5,0xbcdc
+ STEPUP20(40, D2)
+
+ lis %r5,0xca62 /* K60-79 */
+ ori %r5,%r5,0xc1d6
+ STEPUP4(60, D1)
+ STEPUP4(64, D1)
+ STEPUP4(68, D1)
+ STEPUP4(72, D1)
+ STEPD1(76)
+ STEPD1(77)
+ STEPD1(78)
+ STEPD1(79)
+
+ /* Add results to original values */
+ add %r27,%r27,RA(0)
+ add %r28,%r28,RB(0)
+ add %r29,%r29,RC(0)
+ add %r30,%r30,RD(0)
+ add %r31,%r31,RE(0)
+
+ addi %r4,%r4,64
+ bdnz 1b
+
+ /* Save final hash, restore registers, and return */
+ stmw %r27,0(%r3)
+ lmw %r13,-76(%r1)
+ blr
The above changes, if you want them, are placed in the public domain.
It assembles, but I can't test it. Have fun.
(I might also replace "t" with "i" in the macros, but figured that
would make comparing versions annoying. Of course, part of the reason
was confusion with the T register, which is now eliminated...)
^ permalink raw reply
* Catching up: git-pasky-0.6.2 broken?
From: Russell King @ 2005-04-23 11:47 UTC (permalink / raw)
To: git
Hi,
I've been away from git stuff since about Wednesday due to eye problems.
Yesterday and today, I've been trying to catch up, but I'm running into
problems.
I grabbed git-pasky-0.6.2, and followed Linus' message about converting
repositories. I've updated all the "heads", and cleaned out all the old
sha1 files. After updating, I did a read-tree for the tracked head,
followed by checkout-cache -f -a and update-cache --refresh.
Therefore, in theory, everything should be in sync.
However, git pull now has nasty side effects. At first I thought this
was down to something still being out of sync. However, on the second
pull, it's still producing the same complaints.
It's almost although git has a single patch file subversely written into
it to apply lpfc and qla changes which it's trying to apply irrespective
of the objects downloaded.
Any ideas what's going on?
First pull
==========
MOTD:
MOTD: Welcome to the Linux Kernel Archive.
MOTD:
MOTD: Due to U.S. Exports Regulations, all cryptographic software on this
MOTD: site is subject to the following legal notice:
MOTD:
MOTD: This site includes publicly available encryption source code
MOTD: which, together with object code resulting from the compiling of
MOTD: publicly available source code, may be exported from the United
MOTD: States under License Exception "TSU" pursuant to 15 C.F.R. Section
MOTD: 740.13(e).
MOTD:
MOTD: This legal notice applies to cryptographic software only.
MOTD: Please see the Bureau of Industry and Security,
MOTD: http://www.bis.doc.gov/ for more information about current
MOTD: U.S. regulations.
MOTD:
receiving file list ... done
00/2609c5adf1ac2cda36a0f0a70edd12f00216a2
...
ff/ba7c235ad94e3c1e0074cb209504e6ea25afe3
sent 6332 bytes received 3234006 bytes 36613.99 bytes/sec
total size is 65480464 speedup is 20.21
receiving file list ... done
client: nothing to do: perhaps you need to specify some filenames or the --recursive option?
Tree change: c4d541106bc5d0a2134aaf9e8735eee3c70b0db2:efab7739d99eae948971140b2aa3dddf7f72c900
*100644->100644 blob 8e5f9bbdf4de94a1bc4b4da8cb06677ce0a57716->8da3a306d0c0c070d87048d14a033df02f40a154 Makefile
*100644->100644 blob faab8c2a03ebda9eb4e12c35f5398733320484f0->3864b33562ee973643c7800e1129c1fa3239d2ed arch/alpha/kernel/systbls.S
*100644->100644 blob 8d182e875cd72e64b49869386bf090ba23df6793->16dbc4151be43b8e671869b2a52220f47ec0b6ac arch/i386/kernel/cpu/amd.c
*100644->100644 blob 6a717d4d2bc5d44f07b57c01683196ef7f51f349->c60785c046bebd09452b3c73b54df90e6dd3a937 arch/sparc64/kernel/time.c
*100644->100644 blob f94ea8a44051524639412986ac1d86677df5c9c2->f80bafee8669fbcb0420d6e5173ea1f79e863082 arch/x86_64/lib/getuser.S
*100644->100644 blob 0dee1fdcb16280d3d0bb0053ab8634072adfda45->5828b8191667da13f3295034a685f474746ce3b2 arch/x86_64/lib/putuser.S
*100644->100644 blob 97ff364c04341ef866ecd4d70e60e0a1e415b743->6cb0b586c29761d2e3873219a692f83ace1017d6 drivers/ieee1394/ohci1394.c
*100644->100644 blob 3c092117a8eae4a7916967b065ac447f999946e9->260a323a96d38c07003f80b92c2b3dad5c2c025a drivers/isdn/i4l/isdn_ppp.c
*100644->100644 blob 12de80884b1aa6e4240e5a40360369b9dd9b270b->f65ca3b2da6f3fcdb464cd8f9d0b53b5611103b1 drivers/net/tg3.c
*100644->100644 blob d48887d9032501413515a7b53fcb183737de490f->8de6f21037bae13910b0f9c8f075a8d38b89db69 drivers/net/tg3.h
*100644->100644 blob bf3273eb1c8b78764d4b7c563a2585181925e9a4->49d1cd99d5accfadf2eb276644f57a8f1ffec27a drivers/sbus/char/rtc.c
*100644->100644 blob d74b99dab7ec8d11003a176fa4685f2b9f85c4ae->e60f9338e44ad4a2eb938adcc70a491c9a09815d drivers/scsi/aic7xxx/aic7xxx_osm.c
*100644->100644 blob 8caaf2e5e47c01815e5e570b67d1c329a0e91402->39b788d95e39d9eb8f11578552f03933ad0b4e52 drivers/serial/sunsab.c
*100644->100644 blob 23d19d39432080cf72a1b9ecfee9ca8a7c5eda4e->ddc97c905e14cc7a158a22f339379d0129e81551 drivers/serial/sunsu.c
*100644->100644 blob 3099630d0c3d0b0e4cd17513085c1c1500784dc3->9d9d2009ad8caa3af457d263afa5c8717227016a drivers/video/tgafb.c
*100644->100644 blob c4e70e8617eb6b269891c06ace602dce81f12998->535bc425f243bd7cb9fd0b469c50cc2d3bdb102c include/asm-alpha/unistd.h
*100644->100644 blob 925d54cee475ed9976455fddb35f8768f6020ff0->7232528e2d0c13771f6f62af20de13455aedb30b include/asm-ia64/bitops.h
*100644->100644 blob 7c357dfbae50dc400b63c39e0f6add7a214a28a7->4fb4e439b05c35eca06daf2762936939c3e1b333 include/asm-ia64/gcc_intrin.h
*100644->100644 blob ccf2f5f82d7f516b29f8ce841d24e394612f4b47->1f9b1356a48e9e84261676e449597ba05ecaaf88 include/asm-sparc64/mostek.h
*100644->100644 blob af9bf175a223cf44310293287d50302e0fd3f9e9->ae2cd5b09a7cc523e96640d805eb97e299da8907 include/asm-sparc64/pgtable.h
*100644->100644 blob 11efa474865bd20eef9b0a13f42749a6e999da2a->d1f91a4f24ae59f78ed81dbed825cb09f9677e5c include/asm-sparc64/spinlock.h
*100644->100644 blob f1f75fde8cd46d668b5fe68b64259939a0f0f17a->6a1897481942e5dcfd1314d5f7b81e2c6ae36280 include/linux/pci_ids.h
*100644->100644 blob aa35797ebfbf773fae3203094d6c6628ed7bcf35->22b701819619cd6403b834284deecdbdcfb553d4 include/linux/skbuff.h
*100644->100644 blob fb95ecb6fe0357de875dd66896b4d48a731927d4->875edbba396d2601fce49e8e1c88f90195b56698 include/net/ax25.h
*100644->100644 blob d1fea5c3dda1b08989e8acfed841129e229421b5->876dbac71060860956f2e939c81efe2b91512775 net/appletalk/ddp.c
*100644->100644 blob 33f1685dbb771abd4db19520fa709a701909421c->a57a9268bd2436e565cdaf1e15cc9dcf10bb14c7 net/atm/resources.c
*100644->100644 blob 6ff803154c046d6e174713951962331e1fef7548->f7c449ac1800cffe9cb355806886f7d1d19e8950 net/atm/signaling.c
*100644->100644 blob 33b1a376302702fea9de736808a7923b0695e9b1->707097deac3deb4957741204c7944e01521f3c0f net/ax25/af_ax25.c
*100644->100644 blob 04d711344d559e712f5389315e596684933e1fe1->bba0173e2d6500a44954871389fc5e35396dffa2 net/ax25/ax25_ip.c
*100644->100644 blob 3475a3ac9343e38e2d051402f34676b956fd65cf->94557b1a1fa2acedd47b30c3e51b9733eb02b53a net/ax25/ax25_out.c
*100644->100644 blob 8cf72707af8bbcf7ede4fcf1775887cbe910df6e->99694b57f6f565d36f6787f58c8faa43cced25d2 net/ax25/ax25_subr.c
*100644->100644 blob d69ad90e58116594de2d66a26f9bc78dfa183d95->44dfaf8f04afd7cbde0487a5a35ccef5eb4f48ce net/core/rtnetlink.c
*100644->100644 blob bf02ca9f80ac15bfaddf9ef0624e94c5623802e0->f65b3de590a96ff2ecc7df6b7a4b9020a641e549 net/core/skbuff.c
*100644->100644 blob f52c87a9268a772398e937a80730d576ab32a066->4df4fa3c5de047e3ee099b64b38c4948b2dd406a net/core/sock.c
*100644->100644 blob 9f91a116d91926df3ba936a80f020a6ab1084d2b->bb90a0c3a91eb52020d0db0e8b4f94d30e02d596 net/ipv4/route.c
*100644->100644 blob 6baddfbedca3f90adaef9f22e2e97d889cbdc945->8a213238f2873e8a985bf1c85b1f8f347d8f7d8c net/ipv4/udp.c
*100644->100644 blob 5ffde14ddc09547085f02646e4399053429f3cbd->7196ac2f2d1688d410e2f51973f90c0118549c63 net/ipv6/addrconf.c
*100644->100644 blob 49208ba75094a32c18987070727b4f6998d78680->0f0711417c9da71d7595e6019033b8976d479b03 net/ipv6/ip6_output.c
*100644->100644 blob 5488ad0de4f6bd227665657fc65b7fce4fafcca4->1352c1d9bf4d35f6619d3dce4996b69578bdb2d2 net/ipv6/raw.c
*100644->100644 blob 1db59f11f37d687318ae8cbd5e2ea6e48142ca97->d11747c2a763f27a0a37eae59352bf61891a26b8 net/xfrm/xfrm_state.c
Tracked branch, applying changes...
Fast-forwarding c4d541106bc5d0a2134aaf9e8735eee3c70b0db2 -> efab7739d99eae948971140b2aa3dddf7f72c900
on top of c4d541106bc5d0a2134aaf9e8735eee3c70b0db2...
diff: Documentation/scsi/qla2xxx.revision.notes: No such file or directory
diff: drivers/scsi/qla2xxx/qla_listops.h: No such file or directory
diff: drivers/scsi/scsi_obsolete.h: No such file or directory
The next patch would create the file Documentation/scsi/ChangeLog.lpfc,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file Documentation/scsi/ChangeLog.lpfc.rej
The next patch would create the file Documentation/scsi/lpfc.txt,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file Documentation/scsi/lpfc.txt.rej
The next patch would create the file arch/arm/lib/bitops.h,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file arch/arm/lib/bitops.h.rej
The next patch would create the file drivers/scsi/lpfc/Makefile,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/Makefile.rej
The next patch would create the file drivers/scsi/lpfc/lpfc.h,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc.h.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_attr.c,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_attr.c.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_compat.h,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_compat.h.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_crtn.h,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_crtn.h.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_ct.c,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_ct.c.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_disc.h,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_disc.h.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_els.c,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_els.c.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_hbadisc.c,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_hbadisc.c.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_hw.h,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_hw.h.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_init.c,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_init.c.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_logmsg.h,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_logmsg.h.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_mbox.c,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_mbox.c.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_mem.c,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_mem.c.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_nportdisc.c,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_nportdisc.c.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_scsi.c,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_scsi.c.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_scsi.h,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_scsi.h.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_sli.c,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_sli.c.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_sli.h,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_sli.h.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_version.h,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_version.h.rej
The next patch would create the file drivers/scsi/qla2xxx/qla_attr.c,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/qla2xxx/qla_attr.c.rej
The next patch would create the file Documentation/aoe/todo.txt,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file Documentation/aoe/todo.txt.rej
The next patch would create the file Documentation/kref.txt,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file Documentation/kref.txt.rej
Second pull
===========
MOTD:
MOTD: Welcome to the Linux Kernel Archive.
MOTD:
MOTD: Due to U.S. Exports Regulations, all cryptographic software on this
MOTD: site is subject to the following legal notice:
MOTD:
MOTD: This site includes publicly available encryption source code
MOTD: which, together with object code resulting from the compiling of
MOTD: publicly available source code, may be exported from the United
MOTD: States under License Exception "TSU" pursuant to 15 C.F.R. Section
MOTD: 740.13(e).
MOTD:
MOTD: This legal notice applies to cryptographic software only.
MOTD: Please see the Bureau of Industry and Security,
MOTD: http://www.bis.doc.gov/ for more information about current
MOTD: U.S. regulations.
MOTD:
receiving file list ... done
0d/535d65eea6aa98bcd6e4e4b4f797c1fde76d7b
24/0676f75390f530b4b66521bbaf6b8b1a8e3df4
39/1f2ade8823149f217991eb02911bf3dacce050
43/765d4b40a4a3c64f2a32b684f4041e2f01644d
67/3f29d947909a1be0e3775c633d2067a032541c
68/0815c59c80b53903030462d797b828f903946f
71/30667107cd3ab9d6802b69bab63c7d22f20bd4
72/28a8ff004baa2eea325c0dc1286ef38306828d
73/5cd74942b2cb978b58e687bc398e965b14a6f9
7c/43aea5f7f7d9b96b7d9837fa029e16b62ef5df
8d/3a9291b47f835c43c25d916e400828d590798f
aa/aff8e835197c8bd0cbbbbabb7eefde0aabe1a8
ab/489271df7495243e4e0ca6e1f96cd29eb364a9
b4/467b2d08a139961e709cfb41bd1f9280249155
b4/f26bd7be080b1c231039213e92c654be69dedd
b8/d8b883e6f029e99c35c88f853501740e322131
c4/cb74271bca0d0da13cc650a1021f4c8a0a5b87
ca/1536db339408c146fad0eba08919d4fcc80d97
cc/e8ba589e47e268f952f50e8e84bf1e71e0daea
d5/35fc13bf9828e006c83a3eaf37f343ccbd43af
df/6c6804ce1d383c878ab071bce8125125d96abc
e8/0715f8be1ed15ce5e6721d3787e5f7071e4320
eb/b89be2aa2dba5acbcaf7773414ff7ca51a1b87
ef/3fd7265b67c8b6152ad3557162b8488d142231
sent 592 bytes received 1020532 bytes 18072.99 bytes/sec
total size is 65546393 speedup is 64.19
receiving file list ... done
client: nothing to do: perhaps you need to specify some filenames or the --recursive option?
Tree change: efab7739d99eae948971140b2aa3dddf7f72c900:df6c6804ce1d383c878ab071bce8125125d96abc
*100644->100644 blob 19b02adce68cd315d7d44cc13ab7cdc29bb82c83->ebb89be2aa2dba5acbcaf7773414ff7ca51a1b87 arch/ia64/ia32/ia32_signal.c
*100644->100644 blob 105c7fec8c6d20b128631c1e46fb4c892cd274f9->8d3a9291b47f835c43c25d916e400828d590798f arch/ia64/kernel/head.S
*100644->100644 blob cf3f8014f9ad6fecfb5f0f43d257b539540074a6->ef3fd7265b67c8b6152ad3557162b8488d142231 arch/ia64/kernel/mca_asm.S
*100644->100644 blob 91293388dd2947c67d941f7b487b100bb7060fdc->7c43aea5f7f7d9b96b7d9837fa029e16b62ef5df arch/ia64/kernel/process.c
*100644->100644 blob 5318f0cbfc260b3bd3295a5fd0b9daffe045d0c7->ca1536db339408c146fad0eba08919d4fcc80d97 arch/ia64/kernel/smpboot.c
*100644->100644 blob ea1ed377de4cf5d7577b98a120267973abbdfce5->240676f75390f530b4b66521bbaf6b8b1a8e3df4 include/asm-ia64/sal.h
Tracked branch, applying changes...
Fast-forwarding efab7739d99eae948971140b2aa3dddf7f72c900 -> df6c6804ce1d383c878ab071bce8125125d96abc
on top of efab7739d99eae948971140b2aa3dddf7f72c900...
diff: Documentation/scsi/qla2xxx.revision.notes: No such file or directory
diff: drivers/scsi/qla2xxx/qla_listops.h: No such file or directory
diff: drivers/scsi/scsi_obsolete.h: No such file or directory
The next patch would create the file Documentation/scsi/ChangeLog.lpfc,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file Documentation/scsi/ChangeLog.lpfc.rej
The next patch would create the file Documentation/scsi/lpfc.txt,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file Documentation/scsi/lpfc.txt.rej
The next patch would create the file arch/arm/lib/bitops.h,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file arch/arm/lib/bitops.h.rej
The next patch would create the file drivers/scsi/lpfc/Makefile,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/Makefile.rej
The next patch would create the file drivers/scsi/lpfc/lpfc.h,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc.h.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_attr.c,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_attr.c.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_compat.h,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_compat.h.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_crtn.h,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_crtn.h.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_ct.c,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_ct.c.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_disc.h,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_disc.h.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_els.c,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_els.c.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_hbadisc.c,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_hbadisc.c.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_hw.h,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_hw.h.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_init.c,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_init.c.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_logmsg.h,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_logmsg.h.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_mbox.c,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_mbox.c.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_mem.c,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_mem.c.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_nportdisc.c,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_nportdisc.c.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_scsi.c,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_scsi.c.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_scsi.h,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_scsi.h.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_sli.c,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_sli.c.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_sli.h,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_sli.h.rej
The next patch would create the file drivers/scsi/lpfc/lpfc_version.h,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/lpfc/lpfc_version.h.rej
The next patch would create the file drivers/scsi/qla2xxx/qla_attr.c,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/scsi/qla2xxx/qla_attr.c.rej
The next patch would create the file Documentation/aoe/todo.txt,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file Documentation/aoe/todo.txt.rej
The next patch would create the file Documentation/kref.txt,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file Documentation/kref.txt.rej
--
Russell King
^ permalink raw reply
* Re: Git for redundant mail servers
From: Jon Seymour @ 2005-04-23 8:24 UTC (permalink / raw)
To: David Woodhouse; +Cc: git
In-Reply-To: <1114238562.3419.29.camel@localhost.localdomain>
On 4/23/05, David Woodhouse <dwmw2@infradead.org> wrote:
> Random alternative use for git... we could use it to provide a cluster
> of redundant mail delivery/storage servers.
>
> The principle is simple; you use something like a set of Maildir
> folders, stored in a git repository. Any action on the mail storage is
> done as a commit -- that includes delivery of new mail, or user actions
> from the IMAP server such as changing flags, deleting or moving mail.
> These actions are actually fairly efficient when Maildir folders are
> stored in a git repository -- the IMAP model is that mails are
> immutable, and flag changes are done as renames.
>
> In the normal case where all the servers are online, each commit is
> immediately pushed to each remote server. When a server is offline or
> separated somehow from the rest of the group, it's going to have to do a
> merge when it reconnects -- we'd implement a Maildir-specific merge
> algorithm, which really isn't that hard to do.
>
This is a cool idea. When the concept is rendered this way, it sounds
a lot like some of the core principles in the architecture of the
Lotus Notes replication engine. I've always thought it would be cool
to have an open engine that provided similar functionality to the
Lotus Notes replication engine without the naff programming
environment that sits on top. I can see how the git concepts and code
could provide the basis of such a solution. Very cool.
jon.
^ permalink raw reply
* [PATCH] Give better default modes to merge results.
From: Junio C Hamano @ 2005-04-23 7:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
As shipped, the example git-merge-one-file-script often leaves
the merge result with not-so-useful mode bits, especially with
glibc 2.0.7 or later whose mkstemp() creates 0600. This
contradicts the way checkout-cache creates new files, which is
to use 0666 (or 0777 for files with executable bit on) and let
the umask mechanism to take care of the rest.
This patch fixes this problem by (1) passing the executable bits
for 3 stages from merge-cache to the merge script, and by (2)
adjusting the example script to make use of that information.
Even without the latter "executable bit" change, it results in a
better result (0644 or 0664 vs 0600).
For backward compatibility with existing merge scripts, the
additional 3 arguments are appended after the filename (i.e. as
$5, $6 and $7) as opposed to more logical sha1-1 mode-1 sha1-2,
mode-2, ... order.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
This one is a resend.
Updated to apply on your
242cdbdd4367c2a2ddd627283aa8da0081b131bc
New "diff-cache" implementation.
git-merge-one-file-script | 37 +++++++++++++++++++++++++++++--------
merge-cache.c | 18 ++++++++++++++----
2 files changed, 43 insertions(+), 12 deletions(-)
--- k/git-merge-one-file-script
+++ l/git-merge-one-file-script
@@ -6,7 +6,9 @@
# $2 - file in branch1 SHA1 (or empty)
# $3 - file in branch2 SHA1 (or empty)
# $4 - pathname in repository
-#
+# $5 - original file executable bit ('x' or '-' or empty)
+# $6 - file in branch1 executable bit ('x' or '-' or empty)
+# $7 - file in branch2 executable bit ('x' or '-' or empty)
#
# Handle some trivial cases.. The _really_ trivial cases have
# been handled already by read-tree, but that one doesn't
@@ -24,17 +26,29 @@ case "${1:-.}${2:-.}${3:-.}" in
#
"$1.." | "$1.$1" | "$1$1.")
rm -f -- "$4"
- update-cache --remove -- "$4"
- exit 0
+ exec update-cache --remove -- "$4"
;;
#
# added in one, or added identically in both
#
".$2." | "..$3" | ".$2$2")
- mv $(unpack-file "${2:-$3}") $4
- update-cache --add -- $4
- exit 0
+
+ # This part is convoluted but necessary to get a sane
+ # default mode bits. We let the shell to honor default
+ # umask when creating the file, and then rely on chmod +x
+ # to again honor umask. It used to "mv" the file created
+ # in mode 0600 by unpack-file to "$4", which was almost
+ # always wrong.
+
+ tmp=$(unpack-file "${2:-$3}") &&
+ rm -f "$4" &&
+ cat "$tmp" >"$4" &&
+ case "$6$7" in
+ *x*) chmod +x "$4" ;;
+ esac &&
+ rm -f "$tmp" || exit
+ exec update-cache --add -- "$4"
;;
#
@@ -50,11 +64,18 @@ case "${1:-.}${2:-.}${3:-.}" in
echo Leaving conflict merge in $src2
exit 1
fi
- cp "$src2" "$4" && update-cache --add -- "$4" && exit 0
+
+ # See comments for ".$2." | "..$3" | ".$2$2" case.
+ rm -f "$4" &&
+ cat "$src2" >"$4" &&
+ case "$5$6$7" in
+ *x*) chmod +x "$4" ;;
+ esac || exit
+ exec update-cache --add -- "$4"
;;
*)
- echo "Not handling case $1 -> $2 -> $3"
+ echo "Not handling case $1($5) -> $2($6) -> $3($7)"
;;
esac
exit 1
--- k/merge-cache.c
+++ l/merge-cache.c
@@ -4,7 +4,7 @@
#include "cache.h"
static const char *pgm = NULL;
-static const char *arguments[5];
+static const char *arguments[8];
static void run_program(void)
{
@@ -18,6 +18,9 @@ static void run_program(void)
arguments[2],
arguments[3],
arguments[4],
+ arguments[5],
+ arguments[6],
+ arguments[7],
NULL);
die("unable to execute '%s'", pgm);
}
@@ -36,17 +39,24 @@ static int merge_entry(int pos, const ch
arguments[2] = "";
arguments[3] = "";
arguments[4] = path;
+ arguments[5] = "";
+ arguments[6] = "";
+ arguments[7] = "";
found = 0;
do {
- static char hexbuf[4][60];
+ static char hexbuf[3][41];
+ static char xbit[3][2];
struct cache_entry *ce = active_cache[pos];
int stage = ce_stage(ce);
if (strcmp(ce->name, path))
break;
found++;
- strcpy(hexbuf[stage], sha1_to_hex(ce->sha1));
- arguments[stage] = hexbuf[stage];
+ strcpy(hexbuf[stage-1], sha1_to_hex(ce->sha1));
+ arguments[stage] = hexbuf[stage-1];
+ xbit[stage-1][0] = (ntohl(ce->ce_mode) & 0100) ? 'x' : '-';
+ xbit[stage-1][1] = 0;
+ arguments[stage+4] = xbit[stage-1];
} while (++pos < active_nr);
if (!found)
die("merge-cache: %s not in the cache", path);
^ permalink raw reply
* Git for redundant mail servers
From: David Woodhouse @ 2005-04-23 6:42 UTC (permalink / raw)
To: git; +Cc: David Gibson, jgarzik
Random alternative use for git... we could use it to provide a cluster
of redundant mail delivery/storage servers.
The principle is simple; you use something like a set of Maildir
folders, stored in a git repository. Any action on the mail storage is
done as a commit -- that includes delivery of new mail, or user actions
from the IMAP server such as changing flags, deleting or moving mail.
These actions are actually fairly efficient when Maildir folders are
stored in a git repository -- the IMAP model is that mails are
immutable, and flag changes are done as renames.
In the normal case where all the servers are online, each commit is
immediately pushed to each remote server. When a server is offline or
separated somehow from the rest of the group, it's going to have to do a
merge when it reconnects -- we'd implement a Maildir-specific merge
algorithm, which really isn't that hard to do.
In this case we'd probably want to make active use of the feature of git
which allows you to prune history. You don't need to keep any history
further back than the commit which will be the common ancestor when a
currently-absent member of the cluster eventually comes back. In the
common case, that will actually be no history at all, since all members
will be present.
You can then have multiple members of a cluster, each running an SMTP
server and allowing for delivery of email, and each running an IMAP
server. Clients can connect to any of the machines and receive IMAP
service, and email will continue to flow inward, as long as at least one
machine in the cluster remains alive.
--
dwmw2
^ permalink raw reply
* Re: First web interface and service API draft
From: Jon Seymour @ 2005-04-23 6:39 UTC (permalink / raw)
To: Christian Meder; +Cc: Jan Harkes, git
In-Reply-To: <1114203423.3207.24.camel@localhost>
On 4/23/05, Christian Meder <chris@absolutegiganten.org> wrote:
> On Fri, 2005-04-22 at 10:23 -0400, Jan Harkes wrote:
> > On Fri, Apr 22, 2005 at 12:41:56PM +0200, Christian Meder wrote:
> > > -------
> > > /<project>/blob/<blob-sha1>
> > > /<project>/commit/<commit-sha1>
> >
> > It is trivial to find an object when given a sha, but to know the object
> > type you'd have to decompress it and check inside. Also the way git
> > stores these things you can't have both a blob and a commit with the
> > same sha anyways.
> >
> > So why not use,
> > /<project/<hexadecimal sha1 representation>
> > will give you the raw object.
>
> Hmm. I'm not sure about throwing away the <objecttype> information in
> the url. I think I'd prefer to retain the blob, tree and commit
> namespaces because I think they help API users to explicitly state what
> kind of object they expect. I can't think of a scenario where I'd want a
> <sha1> of unknown type. Do you have a specific use case in mind ?
>
I was initially inclined to agree with Jan, but on brief reflection I
think Christian is correct to want to preserve the type info in the
URI. There are numerous reasons why this is a good idea:
- both carbon and silicon users of the URI who don't have direct
access to the repository can infer what the URI refers to without
actually fetching it
- programmatically the web server can make request routing decisions
based on the URI alone and is not forced to perfom a relatively
expensive and unnecessary db hit to derive the type.
That said, I can see some value in providing a web-based
type-resolution service.
So, given a URI of the form
/<project>/object/<hexadecimal sha1 representation>
the server should resolve the type of the named object and issue an
HTTP re-direct to the typed URI, e.g.
/<project>/blob/<hexadecimal sha1 representation>
Because browsers tend not to remember redirection sources, external
entities end up recording the typed URIs, but all the benefits of
Jan's suggestion still accrue.
jon.
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
^ permalink raw reply
* Re: [PATCH] #!/bin/sh --> #!/usr/bin/env bash
From: H. Peter Anvin @ 2005-04-23 6:16 UTC (permalink / raw)
To: dwheeler; +Cc: Alecs King, git
In-Reply-To: <4269B424.8010406@dwheeler.com>
David A. Wheeler wrote:
>
> If # of execs is that critical, it probably should not be in
> bash anyway. OpenBSD (at least 3.1)'s bash appears to be in
> /usr/local/bin/bash, NOT /bin/bash.
> I'd go with the /bin/env solution for now;
> it maximizes the "it just works" factor, and
> when it comes time for .in files much of the cogito code (at least)
> will probably be rewritten in Perl, and anything performance-sensitive
> will be in C.
>
Makes sense.
-hpa
^ permalink raw reply
* [PATCH] PPC assembly implementation of SHA1
From: Paul Mackerras @ 2005-04-23 5:33 UTC (permalink / raw)
To: torvalds; +Cc: git
Here is a SHA1 implementation with the core written in PPC assembly.
On my 2GHz G5, it does 218MB/s, compared to 135MB/s for the openssl
version or 45MB/s for the mozilla version.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff -urN git.orig/Makefile git/Makefile
--- git.orig/Makefile 2005-04-22 16:23:44.000000000 +1000
+++ git/Makefile 2005-04-22 16:43:31.000000000 +1000
@@ -34,9 +34,14 @@
SHA1_HEADER="mozilla-sha1/sha1.h"
LIB_OBJS += mozilla-sha1/sha1.o
else
+ifdef PPC_SHA1
+ SHA1_HEADER="ppc/sha1.h"
+ LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o
+else
SHA1_HEADER=<openssl/sha.h>
LIBS += -lssl
endif
+endif
CFLAGS += '-DSHA1_HEADER=$(SHA1_HEADER)'
@@ -77,7 +82,7 @@
write-tree.o: $(LIB_H)
clean:
- rm -f *.o mozilla-sha1/*.o $(PROG) $(LIB_FILE)
+ rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE)
backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
diff -urN git.orig/ppc/sha1.c git/ppc/sha1.c
--- /dev/null 2005-04-04 12:56:19.000000000 +1000
+++ git/ppc/sha1.c 2005-04-22 16:29:19.000000000 +1000
@@ -0,0 +1,72 @@
+/*
+ * SHA-1 implementation.
+ *
+ * Copyright (C) 2005 Paul Mackerras <paulus@samba.org>
+ *
+ * This version assumes we are running on a big-endian machine.
+ * It calls an external sha1_core() to process blocks of 64 bytes.
+ */
+#include <stdio.h>
+#include <string.h>
+#include "sha1.h"
+
+extern void sha1_core(uint32_t *hash, const unsigned char *p,
+ unsigned int nblocks);
+
+int SHA1_Init(SHA_CTX *c)
+{
+ c->hash[0] = 0x67452301;
+ c->hash[1] = 0xEFCDAB89;
+ c->hash[2] = 0x98BADCFE;
+ c->hash[3] = 0x10325476;
+ c->hash[4] = 0xC3D2E1F0;
+ c->len = 0;
+ c->cnt = 0;
+ return 0;
+}
+
+int SHA1_Update(SHA_CTX *c, const void *ptr, unsigned long n)
+{
+ unsigned long nb;
+ const unsigned char *p = ptr;
+
+ c->len += n << 3;
+ while (n != 0) {
+ if (c->cnt || n < 64) {
+ nb = 64 - c->cnt;
+ if (nb > n)
+ nb = n;
+ memcpy(&c->buf.b[c->cnt], p, nb);
+ if ((c->cnt += nb) == 64) {
+ sha1_core(c->hash, c->buf.b, 1);
+ c->cnt = 0;
+ }
+ } else {
+ nb = n >> 6;
+ sha1_core(c->hash, p, nb);
+ nb <<= 6;
+ }
+ n -= nb;
+ p += nb;
+ }
+ return 0;
+}
+
+int SHA1_Final(unsigned char *hash, SHA_CTX *c)
+{
+ unsigned int cnt = c->cnt;
+
+ c->buf.b[cnt++] = 0x80;
+ if (cnt > 56) {
+ if (cnt < 64)
+ memset(&c->buf.b[cnt], 0, 64 - cnt);
+ sha1_core(c->hash, c->buf.b, 1);
+ cnt = 0;
+ }
+ if (cnt < 56)
+ memset(&c->buf.b[cnt], 0, 56 - cnt);
+ c->buf.l[7] = c->len;
+ sha1_core(c->hash, c->buf.b, 1);
+ memcpy(hash, c->hash, 20);
+ return 0;
+}
diff -urN git.orig/ppc/sha1.h git/ppc/sha1.h
--- /dev/null 2005-04-04 12:56:19.000000000 +1000
+++ git/ppc/sha1.h 2005-04-22 16:45:28.000000000 +1000
@@ -0,0 +1,20 @@
+/*
+ * SHA-1 implementation.
+ *
+ * Copyright (C) 2005 Paul Mackerras <paulus@samba.org>
+ */
+#include <stdint.h>
+
+typedef struct sha_context {
+ uint32_t hash[5];
+ uint32_t cnt;
+ uint64_t len;
+ union {
+ unsigned char b[64];
+ uint64_t l[8];
+ } buf;
+} SHA_CTX;
+
+int SHA1_Init(SHA_CTX *c);
+int SHA1_Update(SHA_CTX *c, const void *p, unsigned long n);
+int SHA1_Final(unsigned char *hash, SHA_CTX *c);
diff -urN git.orig/ppc/sha1ppc.S git/ppc/sha1ppc.S
--- /dev/null 2005-04-04 12:56:19.000000000 +1000
+++ git/ppc/sha1ppc.S 2005-04-22 16:29:19.000000000 +1000
@@ -0,0 +1,185 @@
+/*
+ * SHA-1 implementation for PowerPC.
+ *
+ * Copyright (C) 2005 Paul Mackerras <paulus@samba.org>
+ */
+#define FS 80
+
+/*
+ * We roll the registers for T, A, B, C, D, E around on each
+ * iteration; T on iteration t is A on iteration t+1, and so on.
+ * We use registers 7 - 12 for this.
+ */
+#define RT(t) ((((t)+5)%6)+7)
+#define RA(t) ((((t)+4)%6)+7)
+#define RB(t) ((((t)+3)%6)+7)
+#define RC(t) ((((t)+2)%6)+7)
+#define RD(t) ((((t)+1)%6)+7)
+#define RE(t) ((((t)+0)%6)+7)
+
+/* We use registers 16 - 31 for the W values */
+#define W(t) (((t)%16)+16)
+
+#define STEPD0(t) \
+ and %r6,RB(t),RC(t); \
+ andc %r0,RD(t),RB(t); \
+ rotlwi RT(t),RA(t),5; \
+ rotlwi RB(t),RB(t),30; \
+ or %r6,%r6,%r0; \
+ add %r0,RE(t),%r15; \
+ add RT(t),RT(t),%r6; \
+ add %r0,%r0,W(t); \
+ add RT(t),RT(t),%r0
+
+#define STEPD1(t) \
+ xor %r6,RB(t),RC(t); \
+ rotlwi RT(t),RA(t),5; \
+ rotlwi RB(t),RB(t),30; \
+ xor %r6,%r6,RD(t); \
+ add %r0,RE(t),%r15; \
+ add RT(t),RT(t),%r6; \
+ add %r0,%r0,W(t); \
+ add RT(t),RT(t),%r0
+
+#define STEPD2(t) \
+ and %r6,RB(t),RC(t); \
+ and %r0,RB(t),RD(t); \
+ rotlwi RT(t),RA(t),5; \
+ rotlwi RB(t),RB(t),30; \
+ or %r6,%r6,%r0; \
+ and %r0,RC(t),RD(t); \
+ or %r6,%r6,%r0; \
+ add %r0,RE(t),%r15; \
+ add RT(t),RT(t),%r6; \
+ add %r0,%r0,W(t); \
+ add RT(t),RT(t),%r0
+
+#define LOADW(t) \
+ lwz W(t),(t)*4(%r4)
+
+#define UPDATEW(t) \
+ xor %r0,W((t)-3),W((t)-8); \
+ xor W(t),W((t)-16),W((t)-14); \
+ xor W(t),W(t),%r0; \
+ rotlwi W(t),W(t),1
+
+#define STEP0LD4(t) \
+ STEPD0(t); LOADW((t)+4); \
+ STEPD0((t)+1); LOADW((t)+5); \
+ STEPD0((t)+2); LOADW((t)+6); \
+ STEPD0((t)+3); LOADW((t)+7)
+
+#define STEPUP4(t, fn) \
+ STEP##fn(t); UPDATEW((t)+4); \
+ STEP##fn((t)+1); UPDATEW((t)+5); \
+ STEP##fn((t)+2); UPDATEW((t)+6); \
+ STEP##fn((t)+3); UPDATEW((t)+7)
+
+#define STEPUP20(t, fn) \
+ STEPUP4(t, fn); \
+ STEPUP4((t)+4, fn); \
+ STEPUP4((t)+8, fn); \
+ STEPUP4((t)+12, fn); \
+ STEPUP4((t)+16, fn)
+
+ .globl sha1_core
+sha1_core:
+ stwu %r1,-FS(%r1)
+ stw %r15,FS-68(%r1)
+ stw %r16,FS-64(%r1)
+ stw %r17,FS-60(%r1)
+ stw %r18,FS-56(%r1)
+ stw %r19,FS-52(%r1)
+ stw %r20,FS-48(%r1)
+ stw %r21,FS-44(%r1)
+ stw %r22,FS-40(%r1)
+ stw %r23,FS-36(%r1)
+ stw %r24,FS-32(%r1)
+ stw %r25,FS-28(%r1)
+ stw %r26,FS-24(%r1)
+ stw %r27,FS-20(%r1)
+ stw %r28,FS-16(%r1)
+ stw %r29,FS-12(%r1)
+ stw %r30,FS-8(%r1)
+ stw %r31,FS-4(%r1)
+
+ /* Load up A - E */
+ lwz RA(0),0(%r3) /* A */
+ lwz RB(0),4(%r3) /* B */
+ lwz RC(0),8(%r3) /* C */
+ lwz RD(0),12(%r3) /* D */
+ lwz RE(0),16(%r3) /* E */
+
+ mtctr %r5
+
+1: LOADW(0)
+ LOADW(1)
+ LOADW(2)
+ LOADW(3)
+
+ lis %r15,0x5a82 /* K0-19 */
+ ori %r15,%r15,0x7999
+ STEP0LD4(0)
+ STEP0LD4(4)
+ STEP0LD4(8)
+ STEPUP4(12, D0)
+ STEPUP4(16, D0)
+
+ lis %r15,0x6ed9 /* K20-39 */
+ ori %r15,%r15,0xeba1
+ STEPUP20(20, D1)
+
+ lis %r15,0x8f1b /* K40-59 */
+ ori %r15,%r15,0xbcdc
+ STEPUP20(40, D2)
+
+ lis %r15,0xca62 /* K60-79 */
+ ori %r15,%r15,0xc1d6
+ STEPUP4(60, D1)
+ STEPUP4(64, D1)
+ STEPUP4(68, D1)
+ STEPUP4(72, D1)
+ STEPD1(76)
+ STEPD1(77)
+ STEPD1(78)
+ STEPD1(79)
+
+ lwz %r20,16(%r3)
+ lwz %r19,12(%r3)
+ lwz %r18,8(%r3)
+ lwz %r17,4(%r3)
+ lwz %r16,0(%r3)
+ add %r20,RE(80),%r20
+ add RD(0),RD(80),%r19
+ add RC(0),RC(80),%r18
+ add RB(0),RB(80),%r17
+ add RA(0),RA(80),%r16
+ mr RE(0),%r20
+ stw RA(0),0(%r3)
+ stw RB(0),4(%r3)
+ stw RC(0),8(%r3)
+ stw RD(0),12(%r3)
+ stw RE(0),16(%r3)
+
+ addi %r4,%r4,64
+ bdnz 1b
+
+ lwz %r15,FS-68(%r1)
+ lwz %r16,FS-64(%r1)
+ lwz %r17,FS-60(%r1)
+ lwz %r18,FS-56(%r1)
+ lwz %r19,FS-52(%r1)
+ lwz %r20,FS-48(%r1)
+ lwz %r21,FS-44(%r1)
+ lwz %r22,FS-40(%r1)
+ lwz %r23,FS-36(%r1)
+ lwz %r24,FS-32(%r1)
+ lwz %r25,FS-28(%r1)
+ lwz %r26,FS-24(%r1)
+ lwz %r27,FS-20(%r1)
+ lwz %r28,FS-16(%r1)
+ lwz %r29,FS-12(%r1)
+ lwz %r30,FS-8(%r1)
+ lwz %r31,FS-4(%r1)
+ addi %r1,%r1,FS
+ blr
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.6.3 && request for testing
From: Barry K. Nathan @ 2005-04-23 5:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: Barry K. Nathan, git
In-Reply-To: <20050422103737.GC14565@pasky.ji.cz>
On Fri, Apr 22, 2005 at 12:37:37PM +0200, Petr Baudis wrote:
> Duh, segfaulting sed! Could you please check which of the sed
> invocations actually segfault for you?
"")
echo; sed -re '
/
*Signed-off-by.*/Is//'$colsignoff'&'$coldefault'/
s/^/ /
'
;;
This only happens with an old sed from Mandrake 10.1; as I previously
mentioned, if I install the Mandriva 2005 LE sed package, then the
problem goes away. (And as I previously mentioned, I also need to have
the Mandriva mktemp package installed for git-pasky to work.)
> Thanks,
You're welcome.
-Barry K. Nathan <barryn@pobox.com>
^ permalink raw reply
* [PATCH] fix git log time display for western timezones
From: Nicolas Pitre @ 2005-04-23 3:06 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
It appears that the date command doesn't know how to substract time and
always adds it. The time zone fixup has to be done separately otherwise
time displayed in a negative time zone is wrong.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Index: gitlog.sh
===================================================================
--- 2a91836b5814ffacb1fde000dfb1e55457761c88/gitlog.sh (mode:100755 sha1:53b55be31b38b2ab88434cf1ac0a868700e64525)
+++ uncommitted/gitlog.sh (mode:100775)
@@ -56,8 +56,9 @@
date=(${rest#*> })
sec=${date[0]}; tz=${date[1]}
- dtz=${tz/+/+ }; dtz=${dtz/-/- }
- pdate="$(date -Rud "1970-01-01 UTC + $sec sec $dtz" 2>/dev/null)"
+ dtz=${tz/+/}
+ lsec=$(expr $dtz / 100 \* 3600 + $dtz % 100 \* 60 + $sec)
+ pdate="$(date -Rud "1970-01-01 UTC + $lsec sec" 2>/dev/null)"
if [ "$pdate" ]; then
echo -n $color$key $rest | sed "s/>.*/> ${pdate/+0000/$tz}/"
echo $coldefault
^ permalink raw reply
* Re: [PATCH] #!/bin/sh --> #!/usr/bin/env bash
From: David A. Wheeler @ 2005-04-23 2:34 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Alecs King, git
In-Reply-To: <4268A9C5.5090102@zytor.com>
> Alecs King wrote:
>
>>
>> And as for bash, only gitdiff-do and gitlog.sh 'explicitly' use bash
>> instead of /bin/sh. On most Linux distros, /bin/sh is just a symbolic
>> link to bash. But not on some others. I found gitlsobj.sh could not
>> work using a plain /bin/sh on fbsd. To make life easier, i think it
>> might be better if we all explicitly use bash for all shell scripts.
H. Peter Anvin wrote:
> How about #!/bin/bash (build from .in files if you feel it necessary to
> support systems which don't have bash in /bin) instead of doubling the
> number of execs?
If # of execs is that critical, it probably should not be in
bash anyway. OpenBSD (at least 3.1)'s bash appears to be in
/usr/local/bin/bash, NOT /bin/bash.
I'd go with the /bin/env solution for now;
it maximizes the "it just works" factor, and
when it comes time for .in files much of the cogito code (at least)
will probably be rewritten in Perl, and anything performance-sensitive
will be in C.
--- David A. Wheeler
^ permalink raw reply
* [pasky] tags issue on mirrors
From: Martin Schlemmer @ 2005-04-23 0:19 UTC (permalink / raw)
To: GIT Mailing Lists; +Cc: Petr Baudis
[-- Attachment #1: Type: text/plain, Size: 177 bytes --]
Hi,
Just check, you currently have:
rsync://rsync.kernel.org/pub/scm/cogito/cogito.git/tags/tags
Both with the same tag files.
Cheers,
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.6.3 && request for testing
From: Linus Torvalds @ 2005-04-23 0:18 UTC (permalink / raw)
To: Petr Baudis; +Cc: Greg KH, git
In-Reply-To: <Pine.LNX.4.58.0504221621280.2344@ppc970.osdl.org>
On Fri, 22 Apr 2005, Linus Torvalds wrote:
>
> I'm not even going to debug this bug. I'm just going to rewrite diff-cache
> to do what I should have done originally, ie use the power of the
> in-memory cache.
Done, and pushed out. It should hopefully work now.
Linus
^ permalink raw reply
* Re: [PATCH] multi item packed files
From: Chris Mason @ 2005-04-22 23:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Krzysztof Halasa, git
In-Reply-To: <200504221632.26278.mason@suse.com>
On Friday 22 April 2005 16:32, Chris Mason wrote:
> If I pack every 64k (uncompressed), the checkout-tree time goes down to
> 3m14s. That's a very big difference considering how stupid my code is .git
> was only 20% smaller with 64k chunks. I should be able to do better...I'll
> do one more run.
>
This run also packed tree files together (everything produced by write-tree
went into a packed file), but not the commits. I estimate I could save about
another 168m by packing the tree files and commits into the same file with
the blobs, but this wouldn't make any of the times below faster.
git - original (28k commits) packed
FS size 2,675,408k 1,723,820k
read-tree 24.45s 18.9s
checkout-cache 4m30s 3m5s
patch time 2h30m 1h55m
The format for the packed files could be smarter, such that it didn't require
decompressing the whole packed file to read one item. I would guess I could
get another 20% checkout-cache performance out of it via more tuning, and
probably another 10% of space savings.
Of course, none of this is likely to convince you ;) If you decide later on
it's worthwhile, I don't think it would be difficult to add then.
-chris
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox