From owner-freebsd-arch@FreeBSD.ORG Mon Aug 1 18:25:45 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D50E716A41F; Mon, 1 Aug 2005 18:25:45 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id C139243D46; Mon, 1 Aug 2005 18:25:44 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 6FB1DEB4A2C; Tue, 2 Aug 2005 02:25:40 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 119601379BC; Tue, 2 Aug 2005 02:25:36 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85075-20; Tue, 2 Aug 2005 02:25:23 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id EA36913762A; Tue, 2 Aug 2005 02:25:18 +0800 (CST) Date: Tue, 2 Aug 2005 02:25:18 +0800 From: Xin LI To: freebsd-arch@FreeBSD.org, freebsd-amd64@FreeBSD.org Message-ID: <20050801182518.GA85423@frontfree.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.4-RELEASE-p6 FreeBSD 5.4-RELEASE-p6 #4: Thu Jul 28 10:59:26 CST 2005 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: amavisd-new at frontfree.net Cc: obrien@FreeBSD.org Subject: [RFC] Port of NetBSD's optimized amd64 string code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 18:25:46 -0000 --EuxKj2iCbKjpUGkD Content-Type: multipart/mixed; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Guys, Here is a patchset that I have produced to make our libc aware of the NetBSD assembly implementation of the string related operations. Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-libc::amd64-string" Content-Transfer-Encoding: quoted-printable Index: Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/lib/libc/amd64/string/Makefile.inc,v retrieving revision 1.5 diff -u -r1.5 Makefile.inc --- Makefile.inc 10 Apr 2005 18:58:49 -0000 1.5 +++ Makefile.inc 1 Aug 2005 18:18:29 -0000 @@ -1,4 +1,5 @@ # $FreeBSD: src/lib/libc/amd64/string/Makefile.inc,v 1.5 2005/04/10 18:58:= 49 alc Exp $ =20 -MDSRCS+=3D bcmp.S bcopy.S bzero.S memcmp.S memcpy.S memmove.S memset.S \ - strcat.S strcmp.S strcpy.S +MDSRCS+=3D bcmp.S bcopy.S bzero.S ffs.S index.S memchr.S memcmp.S memcpy.S= \ + memmove.S memset.S rindex.S strcat.S strchr.S strcmp.S strcpy.S \ + strlen.S strncmp.S strrchr.S swab.S Index: ffs.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: ffs.S diff -N ffs.S --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ ffs.S 1 Aug 2005 17:54:04 -0000 @@ -0,0 +1,22 @@ +/* + * Written by J.T. Conklin . + * Public domain. + * Adapted for NetBSD/x86_64 by Frank van der Linden + */ + +#include +__FBSDID("$FreeBSD$"); + +#if 0 + RCSID("$NetBSD: ffs.S,v 1.2 2003/07/26 19:24:38 salo Exp $") +#endif + +ENTRY(ffs) + bsfl %edi,%eax + jz L1 /* ZF is set if all bits are 0 */ + incl %eax /* bits numbered from 1, not 0 */ + ret + + .align 4 +L1: xorl %eax,%eax /* clear result */ + ret Index: index.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: index.S diff -N index.S --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ index.S 1 Aug 2005 18:08:21 -0000 @@ -0,0 +1,5 @@ +/* $NetBSD: index.S,v 1.3 2004/07/19 20:04:41 drochner Exp $ */ +/* $FreeBSD$ */ + +#define INDEX +#include "strchr.S" Index: memchr.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: memchr.S diff -N memchr.S --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ memchr.S 1 Aug 2005 18:09:44 -0000 @@ -0,0 +1,112 @@ +/* + * Written by J.T. Conklin + * Public domain. + */ + +#include +__FBSDID("$FreeBSD$"); + +#if 0 + RCSID("$NetBSD: memchr.S,v 1.3 2004/07/19 20:04:41 drochner Exp $") +#endif + +ENTRY(memchr) + movzbq %sil,%rcx + + /* + * Align to word boundry + * Consider unrolling loop? + */ + testq %rdx,%rdx /* nbytes =3D=3D 0? */ + je .Lzero +.Lalign: + testb $7,%dil + je .Lword_aligned + movq %rdi,%rax + cmpb (%rdi),%cl + je .Ldone + incq %rdi + decq %rdx + jnz .Lalign + jmp .Lzero + +.Lword_aligned: + /* copy char to all bytes in word */ + movb %cl,%ch + movq %rcx,%rsi + salq $16,%rcx + orq %rsi,%rcx + movq %rcx,%rsi + salq $32,%rcx + orq %rsi,%rcx + + movabsq $0x0101010101010101,%r8 + movabsq $0x8080808080808080,%r9 + + .align 4 +.Lloop: + cmpq $7,%rdx /* nbytes > 8 */ + jbe .Lbyte + movq (%rdi),%rsi + addq $8,%rdi + xorq %rcx,%rsi + subq $8,%rdx + subq %r8,%rsi + testq %r9,%rsi + je .Lloop + + /* + * In rare cases, the above loop may exit prematurely. We must + * return to the loop if none of the bytes in the word are + * equal to ch. + */ + + leaq -8(%rdi),%rax + cmpb -8(%rdi),%cl /* 1st byte =3D=3D ch? */ + je .Ldone + + leaq -7(%rdi),%rax + cmpb -7(%rdi),%cl /* 2nd byte =3D=3D ch? */ + je .Ldone + + leaq -6(%rdi),%rax + cmpb -6(%rdi),%cl /* 3rd byte =3D=3D ch? */ + je .Ldone + + leaq -5(%rdi),%rax + cmpb -5(%rdi),%cl /* 4th byte =3D=3D ch? */ + je .Ldone + + leaq -4(%rdi),%rax + cmpb -4(%rdi),%cl /* 5th byte =3D=3D ch? */ + je .Ldone + + leaq -3(%rdi),%rax + cmpb -3(%rdi),%cl /* 6th byte =3D=3D ch? */ + je .Ldone + + leaq -2(%rdi),%rax + cmpb -2(%rdi),%cl /* 7th byte =3D=3D ch? */ + je .Ldone + + leaq -1(%rdi),%rax + cmpb -1(%rdi),%cl /* 7th byte =3D=3D ch? */ + jne .Lloop + ret + +.Lbyte: + testq %rdx,%rdx + je .Lzero +.Lbyte_loop: + movq %rdi,%rax + cmpb (%rdi),%cl + je .Ldone + incq %rdi + decq %rdx + jnz .Lbyte_loop + +.Lzero: + xorq %rax,%rax + +.Ldone: + ret Index: rindex.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: rindex.S diff -N rindex.S --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ rindex.S 1 Aug 2005 18:10:36 -0000 @@ -0,0 +1,5 @@ +/* $NetBSD: rindex.S,v 1.3 2004/07/19 20:04:41 drochner Exp $ */ +/* $FreeBSD$ */ + +#define RINDEX +#include "strrchr.S" Index: strchr.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: strchr.S diff -N strchr.S --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ strchr.S 1 Aug 2005 18:11:51 -0000 @@ -0,0 +1,137 @@ +/* + * Written by J.T. Conklin + * Public domain. + */ + +#include +__FBSDID("$FreeBSD$"); + +#if 0 + RCSID("$NetBSD: strchr.S,v 1.2 2004/07/19 20:04:41 drochner Exp $") +#endif + +#ifdef INDEX +ENTRY(index) +#else +ENTRY(strchr) +#endif + movzbq %sil,%rcx + + /* + * Align to word boundary. + * Consider unrolling loop? + */ +.Lalign: + testb $7,%dil + je .Lword_aligned + movb (%rdi),%dl + cmpb %cl,%dl + je .Ldone + incq %rdi + testb %dl,%dl + jne .Lalign + jmp .Lzero + +.Lword_aligned: + /* copy char to all bytes in word */ + movb %cl,%ch + movq %rcx,%rdx + salq $16,%rcx + orq %rdx,%rcx + movq %rcx,%rdx + salq $32,%rcx + orq %rdx,%rcx + + movabsq $0x0101010101010101,%r8 + movabsq $0x8080808080808080,%r9 + + /* Check whether any byte in the word is equal to ch or 0. */ + .align 4 +.Lloop: + movq (%rdi),%rdx + addq $8,%rdi + movq %rdx,%rsi + subq %r8,%rdx + xorq %rcx,%rsi + subq %r8,%rsi + orq %rsi,%rdx + testq %r9,%rdx + je .Lloop + + /* + * In rare cases, the above loop may exit prematurely. We must + * return to the loop if none of the bytes in the word match + * ch or are equal to 0. + */ + + movb -8(%rdi),%dl + cmpb %cl,%dl /* 1st byte =3D=3D ch? */ + jne 1f + subq $8,%rdi + jmp .Ldone +1: testb %dl,%dl /* 1st byte =3D=3D 0? */ + je .Lzero + + movb -7(%rdi),%dl + cmpb %cl,%dl /* 2nd byte =3D=3D ch? */ + jne 1f + subq $7,%rdi + jmp .Ldone +1: testb %dl,%dl /* 2nd byte =3D=3D 0? */ + je .Lzero + + movb -6(%rdi),%dl + cmpb %cl,%dl /* 3rd byte =3D=3D ch? */ + jne 1f + subq $6,%rdi + jmp .Ldone +1: testb %dl,%dl /* 3rd byte =3D=3D 0? */ + je .Lzero + + movb -5(%rdi),%dl + cmpb %cl,%dl /* 4th byte =3D=3D ch? */ + jne 1f + subq $5,%rdi + jmp .Ldone +1: testb %dl,%dl /* 4th byte =3D=3D 0? */ + je .Lzero + + movb -4(%rdi),%dl + cmpb %cl,%dl /* 5th byte =3D=3D ch? */ + jne 1f + subq $4,%rdi + jmp .Ldone +1: testb %dl,%dl /* 5th byte =3D=3D 0? */ + je .Lzero + + movb -3(%rdi),%dl + cmpb %cl,%dl /* 6th byte =3D=3D ch? */ + jne 1f + subq $3,%rdi + jmp .Ldone +1: testb %dl,%dl /* 6th byte =3D=3D 0? */ + je .Lzero + + movb -2(%rdi),%dl + cmpb %cl,%dl /* 7th byte =3D=3D ch? */ + jne 1f + subq $2,%rdi + jmp .Ldone +1: testb %dl,%dl /* 7th byte =3D=3D 0? */ + je .Lzero + + movb -1(%rdi),%dl + cmpb %cl,%dl /* 8th byte =3D=3D ch? */ + jne 1f + subq $1,%rdi + jmp .Ldone +1: testb %dl,%dl /* 8th byte =3D=3D 0? */ + jne .Lloop + +.Lzero: + /* If a ch wasn't found, return 0. */ + xorq %rdi,%rdi + +.Ldone: + movq %rdi,%rax + ret Index: strlen.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: strlen.S diff -N strlen.S --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ strlen.S 1 Aug 2005 18:12:48 -0000 @@ -0,0 +1,157 @@ +/* + * Written by J.T. Conklin + * Public domain. + */ + +#include +__FBSDID("$FreeBSD$"); + +#if 0 + RCSID("$NetBSD: strlen.S,v 1.3 2004/07/19 20:04:41 drochner Exp $") +#endif + +ENTRY(strlen) + movq %rdi,%rax + negq %rdi + +.Lalign: + /* Consider unrolling loop? */ + testb $7,%al + je .Lword_aligned + cmpb $0,(%rax) + jne 1f + leaq (%rdi,%rax),%rax + ret +1: incq %rax + jmp .Lalign + + /* + * There are many well known branch-free sequences which are used + * for determining whether a zero-byte is contained within a word. + * These sequences are generally much more efficent than loading + * and comparing each byte individually. + * + * The expression [1,2]: + * + * (1) ~(((x & 0x7f....7f) + 0x7f....7f) | (x | 0x7f....7f)) + * + * evaluates to a non-zero value if any of the bytes in the + * original word is zero. + * + * It also has the useful property that bytes in the result word + * that coorespond to non-zero bytes in the original word have + * the value 0x00, while bytes cooresponding to zero bytes have + * the value 0x80. This allows calculation of the first (and + * last) occurance of a zero byte within the word (useful for C's + * str* primitives) by counting the number of leading (or + * trailing) zeros and dividing the result by 8. On machines + * without (or with slow) clz() / ctz() instructions, testing + * each byte in the result word for zero is necessary. + * + * This typically takes 4 instructions (5 on machines without + * "not-or") not including those needed to load the constant. + * + * + * The expression: + * + * (2) ((x - 0x01....01) & ~x & 0x80....80) + * + * evaluates to a non-zero value if any of the bytes in the + * original word is zero. + * + * On little endian machines, the first byte in the result word + * that cooresponds to a zero byte in the original byte is 0x80, + * so clz() can be used as above. On big endian machines, and + * little endian machines without (or with a slow) clz() insn, + * testing each byte in the original for zero is necessary + * + * This typically takes 3 instructions (4 on machines without + * "and with complement") not including those needed to load + * constants. + * + * + * The expression: + * + * (3) ((x - 0x01....01) & 0x80....80) + * + * always evaluates to a non-zero value if any of the bytes in + * the original word is zero. However, in rare cases, it also + * evaluates to a non-zero value when none of the bytes in the + * original word is zero. + * + * To account for possible false positives, each byte of the + * original word must be checked when the expression evaluates to + * a non-zero value. However, because it is simpler than those + * presented above, code that uses it will be faster as long as + * the rate of false positives is low. + * + * This is likely, because the the false positive can only occur + * if the most siginificant bit of a byte within the word is set. + * The expression will never fail for typical 7-bit ASCII strings. + * + * This typically takes 2 instructions not including those needed + * to load constants. + * + * + * [1] Henry S. Warren Jr., "Hacker's Delight", Addison-Westley 2003 + * + * [2] International Business Machines, "The PowerPC Compiler Writer's + * Guide", Warthman Associates, 1996 + */ + + .align 4 +.Lword_aligned: + movabsq $0x0101010101010101,%r8 + movabsq $0x8080808080808080,%r9 +.Lloop: + movq (%rax),%rdx + addq $8,%rax + subq %r8,%rdx + testq %r9,%rdx + je .Lloop + + /* + * In rare cases, the above loop may exit prematurely. We must + * return to the loop if none of the bytes in the word equal 0. + */ + cmpb $0,-8(%rax) /* 1st byte =3D=3D 0? */ + je .Lsub8 + cmpb $0,-7(%rax) /* 2nd byte =3D=3D 0? */ + je .Lsub7 + cmpb $0,-6(%rax) /* 3rd byte =3D=3D 0? */ + je .Lsub6 + cmpb $0,-5(%rax) /* 4th byte =3D=3D 0? */ + je .Lsub5 + cmpb $0,-4(%rax) /* 5th byte =3D=3D 0? */ + je .Lsub4 + cmpb $0,-3(%rax) /* 6th byte =3D=3D 0? */ + je .Lsub3 + cmpb $0,-2(%rax) /* 7th byte =3D=3D 0? */ + je .Lsub2 + cmpb $0,-1(%rax) /* 8th byte =3D=3D 0? */ + jne .Lloop + +.Lsub1: + leaq -1(%rdi,%rax),%rax + ret +.Lsub2: + leaq -2(%rdi,%rax),%rax + ret +.Lsub3: + leaq -3(%rdi,%rax),%rax + ret +.Lsub4: + leaq -4(%rdi,%rax),%rax + ret +.Lsub5: + leaq -5(%rdi,%rax),%rax + ret +.Lsub6: + leaq -6(%rdi,%rax),%rax + ret +.Lsub7: + leaq -7(%rdi,%rax),%rax + ret +.Lsub8: + leaq -8(%rdi,%rax),%rax + ret Index: strncmp.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: strncmp.S diff -N strncmp.S --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ strncmp.S 1 Aug 2005 18:13:51 -0000 @@ -0,0 +1,108 @@ +/* + * Written by J.T. Conklin . + * Public domain. + */ + +#include +__FBSDID("$FreeBSD$"); + +#if 0 + RCSID("$NetBSD: strncmp.S,v 1.2 2003/07/26 19:24:40 salo Exp $") +#endif + +/* + * NOTE: I've unrolled the loop eight times: large enough to make a + * significant difference, and small enough not to totally trash the + * cache. + */ + +ENTRY(strncmp) + testq %rdx,%rdx + jmp L2 /* Jump into the loop! */ + +L1: incq %rdi + incq %rsi + decq %rdx +L2: jz L4 /* strings are equal */ + movb (%rdi),%al + testb %al,%al + jz L3 + cmpb %al,(%rsi) + jne L3 + + incq %rdi + incq %rsi + decq %rdx + jz L4 + movb (%rdi),%al + testb %al,%al + jz L3 + cmpb %al,(%rsi) + jne L3 + + incq %rdi + incq %rsi + decq %rdx + jz L4 + movb (%rdi),%al + testb %al,%al + jz L3 + cmpb %al,(%rsi) + jne L3 + + incq %rdi + incq %rsi + decq %rdx + jz L4 + movb (%rdi),%al + testb %al,%al + jz L3 + cmpb %al,(%rsi) + jne L3 + + incq %rdi + incq %rsi + decq %rdx + jz L4 + movb (%rdi),%al + testb %al,%al + jz L3 + cmpb %al,(%rsi) + jne L3 + + incq %rdi + incq %rsi + decq %rdx + jz L4 + movb (%rdi),%al + testb %al,%al + jz L3 + cmpb %al,(%rsi) + jne L3 + + incq %rdi + incq %rsi + decq %rdx + jz L4 + movb (%rdi),%al + testb %al,%al + jz L3 + cmpb %al,(%rsi) + jne L3 + + incq %rdi + incq %rsi + decq %rdx + jz L4 + movb (%rdi),%al + testb %al,%al + jz L3 + cmpb %al,(%rsi) + je L1 + +L3: movzbl (%rdi),%eax /* unsigned comparision */ + movzbl (%rsi),%ecx + subl %ecx,%eax + ret +L4: xorl %eax,%eax + ret Index: strrchr.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: strrchr.S diff -N strrchr.S --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ strrchr.S 1 Aug 2005 18:15:07 -0000 @@ -0,0 +1,127 @@ +/* + * Written by J.T. Conklin + * Public domain. + */ + +#include +__FBSDID("$FreeBSD$"); + +#if 0 + RCSID("$NetBSD: strrchr.S,v 1.2 2004/07/19 20:04:41 drochner Exp $") +#endif + +#ifdef RINDEX +ENTRY(rindex) +#else +ENTRY(strrchr) +#endif + movzbq %sil,%rcx + + /* zero return value */ + xorq %rax,%rax + + /* + * Align to word boundary. + * Consider unrolling loop? + */ +.Lalign: + testb $7,%dil + je .Lword_aligned + movb (%rdi),%dl + cmpb %cl,%dl + cmoveq %rdi,%rax + incq %rdi + testb %dl,%dl + jne .Lalign + jmp .Ldone + +.Lword_aligned: + /* copy char to all bytes in word */ + movb %cl,%ch + movq %rcx,%rdx + salq $16,%rcx + orq %rdx,%rcx + movq %rcx,%rdx + salq $32,%rcx + orq %rdx,%rcx + + movabsq $0x0101010101010101,%r8 + movabsq $0x8080808080808080,%r9 + + /* Check whether any byte in the word is equal to ch or 0. */ + .align 4 +.Lloop: + movq (%rdi),%rdx + addq $8,%rdi + movq %rdx,%rsi + subq %r8,%rdx + xorq %rcx,%rsi + subq %r8,%rsi + orq %rsi,%rdx + testq %r9,%rdx + je .Lloop + + /* + * In rare cases, the above loop may exit prematurely. We must + * return to the loop if none of the bytes in the word match + * ch or are equal to 0. + */ + + movb -8(%rdi),%dl + cmpb %cl,%dl /* 1st byte =3D=3D ch? */ + jne 1f + leaq -8(%rdi),%rax +1: testb %dl,%dl /* 1st byte =3D=3D 0? */ + je .Ldone + + movb -7(%rdi),%dl + cmpb %cl,%dl /* 2nd byte =3D=3D ch? */ + jne 1f + leaq -7(%rdi),%rax +1: testb %dl,%dl /* 2nd byte =3D=3D 0? */ + je .Ldone + + movb -6(%rdi),%dl + cmpb %cl,%dl /* 3rd byte =3D=3D ch? */ + jne 1f + leaq -6(%rdi),%rax +1: testb %dl,%dl /* 3rd byte =3D=3D 0? */ + je .Ldone + + movb -5(%rdi),%dl + cmpb %cl,%dl /* 4th byte =3D=3D ch? */ + jne 1f + leaq -5(%rdi),%rax +1: testb %dl,%dl /* 4th byte =3D=3D 0? */ + je .Ldone + + movb -4(%rdi),%dl + cmpb %cl,%dl /* 5th byte =3D=3D ch? */ + jne 1f + leaq -4(%rdi),%rax +1: testb %dl,%dl /* 5th byte =3D=3D 0? */ + je .Ldone + + movb -3(%rdi),%dl + cmpb %cl,%dl /* 6th byte =3D=3D ch? */ + jne 1f + leaq -3(%rdi),%rax +1: testb %dl,%dl /* 6th byte =3D=3D 0? */ + je .Ldone + + movb -2(%rdi),%dl + cmpb %cl,%dl /* 7th byte =3D=3D ch? */ + jne 1f + leaq -2(%rdi),%rax +1: testb %dl,%dl /* 7th byte =3D=3D 0? */ + je .Ldone + + movb -1(%rdi),%dl + cmpb %cl,%dl /* 8th byte =3D=3D ch? */ + jne 1f + leaq -1(%rdi),%rax +1: testb %dl,%dl /* 8th byte =3D=3D 0? */ + jne .Lloop + +.Ldone: + ret Index: swab.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: swab.S diff -N swab.S --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ swab.S 1 Aug 2005 18:18:17 -0000 @@ -0,0 +1,47 @@ +/* + * Written by J.T. Conklin . + * Public domain. + */ + +#include +__FBSDID("$FreeBSD$"); + +#if 0 + RCSID("$NetBSD: swab.S,v 1.2 2003/07/26 19:24:40 salo Exp $") +#endif + +#define LOAD_SWAP_STORE_WORD \ + lodsw ; \ + xchgb %al,%ah ; \ + stosw + +ENTRY(swab) + xchgq %rdi,%rsi + cld # set direction forward + + shrq $1,%rdx + testq $7,%rdx # copy first group of 1 to 7 words + jz L2 # while swaping alternate bytes. +L1: lodsw + rorw $8,%ax + stosw + decq %rdx + testq $7,%rdx + jnz L1 + +L2: shrq $3,%rdx # copy remainder 8 words at a time + jz L4 # while swapping alternate bytes. +L3: + LOAD_SWAP_STORE_WORD + LOAD_SWAP_STORE_WORD + LOAD_SWAP_STORE_WORD + LOAD_SWAP_STORE_WORD + LOAD_SWAP_STORE_WORD + LOAD_SWAP_STORE_WORD + LOAD_SWAP_STORE_WORD + LOAD_SWAP_STORE_WORD + + decq %rdx + jnz L3 +L4: + ret --vtzGhvizbBRQ85DL-- --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC7mkO/cVsHxFZiIoRArcuAJ9AF9F0+YFYsQpLVPvnd3hGmKNXBgCdFAIS mrMJ3TeaXKrzkBqS3vxeQGI= =TJe9 -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD-- From owner-freebsd-arch@FreeBSD.ORG Mon Aug 1 22:28:08 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1505016A41F; Mon, 1 Aug 2005 22:28:08 +0000 (GMT) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FD7143D45; Mon, 1 Aug 2005 22:28:07 +0000 (GMT) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.12.11/jtpda-5.4) with ESMTP id j71MS2kv065693 ; Tue, 2 Aug 2005 00:28:02 +0200 (CEST) X-Ids: 165 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id j71MS0TF097301 ; Tue, 2 Aug 2005 00:28:00 +0200 (MEST) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.13.3/8.13.1/Submit) id j71MS0Ep097298; Tue, 2 Aug 2005 00:28:00 +0200 (MEST) (envelope-from arno) To: obrien@freebsd.org References: <53d4293a37f280317d52338c2fc6fc6d@FreeBSD.org> <20050612025402.GD67746@dragon.NUXI.org> <200506151655.52894.jhb@FreeBSD.org> <20050616010629.GA3554@hub.freebsd.org> From: "Arno J. Klaassen" Date: 02 Aug 2005 00:28:00 +0200 In-Reply-To: <20050616010629.GA3554@hub.freebsd.org> Message-ID: Lines: 34 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.2 (shiva.jussieu.fr [134.157.0.165]); Tue, 02 Aug 2005 00:28:02 +0200 (CEST) X-Antivirus: scanned by sophie at shiva.jussieu.fr X-Miltered: at shiva.jussieu.fr with ID 42EEA1F2.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Cc: freebsd-arch@freebsd.org Subject: Re: Death to toor X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 22:28:08 -0000 Hello, [ stuff deleted ] > > > > Is there any good reason to keep the toor account around nowadays? > > > > > > Yes. Some of us use it. from a user point of view, I use toor on all machines, basically for two reasons : - I don't feel confident to change default root shell (might be wrong but I have had way too many problems "solved" by setting SHELL and/or CONFIG_SHELL to yet another one); things are tested with the default shell, OK, I use it when running in problems - quite a lot of my customors "need/want" root access (including the possibility to change it's passwd); keeping a toor account with a well kept secret by me passwd saves me a lot of trouble (a part from systems needing root passwd for catastrophic single user boot) My $0.02 Arno PS, as a side-node I prefer /bin/bash as well since it gave me less headaches on multiple-architecture sites than trying to understand all subtle differences between their different default root shells PS-II, I can add toor by hand anytime; I'm no lawyer nor advocate of whatsoever; providing a "fake" toor account without standard /bin/bash in fact is reasonable to me From owner-freebsd-arch@FreeBSD.ORG Tue Aug 2 00:52:14 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B43916A41F; Tue, 2 Aug 2005 00:52:14 +0000 (GMT) (envelope-from dougb@freebsd.org) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 008FD43D45; Tue, 2 Aug 2005 00:52:13 +0000 (GMT) (envelope-from dougb@freebsd.org) Received: from [192.168.0.3] (c-24-130-110-32.hsd1.ca.comcast.net[24.130.110.32]) by comcast.net (rwcrmhc11) with ESMTP id <2005080200521001300hna9ce>; Tue, 2 Aug 2005 00:52:10 +0000 Message-ID: <42EEC3B9.1090507@FreeBSD.org> Date: Mon, 01 Aug 2005 17:52:09 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Arno J. Klaassen" References: <53d4293a37f280317d52338c2fc6fc6d@FreeBSD.org> <20050612025402.GD67746@dragon.NUXI.org> <200506151655.52894.jhb@FreeBSD.org> <20050616010629.GA3554@hub.freebsd.org> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Death to toor X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 00:52:14 -0000 Arno J. Klaassen wrote: > Hello, > > [ stuff deleted ] > >>>>>Is there any good reason to keep the toor account around nowadays? >>>> >>>>Yes. Some of us use it. > > > from a user point of view, I use toor on all machines, basically for > two reasons : > > - I don't feel confident to change default root shell As long as you change it to another shell that is provided by the system (in this case /bin/sh) you'll be fine here. I've done this for years. My .profile tests to see if bash is available, and execs it if so. Note, I'm not saying that we should get rid of toor, quite the opposite, I think we should keep it. > - quite a lot of my customors "need/want" root access (including the > possibility to change it's passwd); keeping a toor account with a well > kept secret by me passwd saves me a lot of trouble (a part from > systems needing root passwd for catastrophic single user boot) That's an entirely different situation. hth, Doug From owner-freebsd-arch@FreeBSD.ORG Tue Aug 2 01:39:23 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CEC616A41F; Tue, 2 Aug 2005 01:39:23 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02C4143D48; Tue, 2 Aug 2005 01:39:22 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j721dIRR038004; Mon, 1 Aug 2005 18:39:18 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j721dGEX038003; Mon, 1 Aug 2005 18:39:16 -0700 (PDT) (envelope-from obrien) Date: Mon, 1 Aug 2005 18:39:16 -0700 From: "David O'Brien" To: Xin LI Message-ID: <20050802013916.GA37135@dragon.NUXI.org> Mail-Followup-To: freebsd-arch@FreeBSD.org, freebsd-amd64@FreeBSD.org, Xin LI References: <20050801182518.GA85423@frontfree.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050801182518.GA85423@frontfree.net> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-arch@FreeBSD.org, freebsd-amd64@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 01:39:23 -0000 On Tue, Aug 02, 2005 at 02:25:18AM +0800, Xin LI wrote: > Here is a patchset that I have produced to make our libc aware of the > NetBSD assembly implementation of the string related operations. What performance benchmarks have these been thru? -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Tue Aug 2 04:03:00 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1F2B16A41F; Tue, 2 Aug 2005 04:03:00 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C2ED43D49; Tue, 2 Aug 2005 04:03:00 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id DD30FEB1E9F; Tue, 2 Aug 2005 12:02:56 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id B0BE4138359; Tue, 2 Aug 2005 12:02:54 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03769-18; Tue, 2 Aug 2005 12:02:47 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 66BBA138352; Tue, 2 Aug 2005 12:02:46 +0800 (CST) Date: Tue, 2 Aug 2005 12:02:46 +0800 From: Xin LI To: freebsd-arch@FreeBSD.org, freebsd-amd64@FreeBSD.org Message-ID: <20050802040246.GB3799@frontfree.net> References: <20050801182518.GA85423@frontfree.net> <20050802013916.GA37135@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H+4ONPRPur6+Ovig" Content-Disposition: inline In-Reply-To: <20050802013916.GA37135@dragon.NUXI.org> User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.4-RELEASE-p6 FreeBSD 5.4-RELEASE-p6 #4: Thu Jul 28 10:59:26 CST 2005 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: amavisd-new at frontfree.net Cc: Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 04:03:00 -0000 --H+4ONPRPur6+Ovig Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 01, 2005 at 06:39:16PM -0700, David O'Brien wrote: > On Tue, Aug 02, 2005 at 02:25:18AM +0800, Xin LI wrote: > > Here is a patchset that I have produced to make our libc aware of the > > NetBSD assembly implementation of the string related operations. >=20 > What performance benchmarks have these been thru? I'm stilling reading The "Software Optimization Guide for AMD Athlon64 and Opteron" and the disassembly output of latest GCC snapshot to see if we are on the right way. No benchmarks has been done yet, but I will at least test it on Athlon64 tonight to get some numbers, and if I can arrange a test on our Opteron box at company, I will do some benchmarks there, too. BTW. Would you please give me some hints on the benchmarking? I am not sure whether just looping the test cases on some determine dataset would be enough? Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --H+4ONPRPur6+Ovig Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC7vBm/cVsHxFZiIoRAjM2AJ9looDj9eeNKvMm4flnRzJ5eEPeIQCffe1T 2MWnE3syKiMLIla7S6UEENo= =2/BP -----END PGP SIGNATURE----- --H+4ONPRPur6+Ovig-- From owner-freebsd-arch@FreeBSD.ORG Tue Aug 2 04:05:29 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA26216A41F for ; Tue, 2 Aug 2005 04:05:29 +0000 (GMT) (envelope-from yourabi@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3115043D46 for ; Tue, 2 Aug 2005 04:05:29 +0000 (GMT) (envelope-from yourabi@gmail.com) Received: by wproxy.gmail.com with SMTP id i12so1118204wra for ; Mon, 01 Aug 2005 21:05:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=W8ZQzpQ273gaRrVOJt8b2gxReEFOINTSnwTm37FOSvtr/IryBlijNI2x683n0kZvX4g9aIuxJdvSxLRA8Waybs6vlRlT+wTwlQU9EoSrY+pUMs2MgVccXWdxGOugKhTutf9aoQwX4BXcppTt6Kq4qJvVM+1cQcNEtYSA2zSEwZk= Received: by 10.54.43.11 with SMTP id q11mr3477714wrq; Mon, 01 Aug 2005 21:05:27 -0700 (PDT) Received: by 10.54.14.44 with HTTP; Mon, 1 Aug 2005 21:05:27 -0700 (PDT) Message-ID: Date: Mon, 1 Aug 2005 21:05:27 -0700 From: Yousef Ourabi To: arch@freebsd.org, freebsd-arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: 6.0 TCP/IP Stack and Threading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Yousef Ourabi List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 04:05:29 -0000 Hello: I am interested in the changes to the tcp/ip and KSE / scheduler implementation in freebsd 6.0, from the 5.x branch. Is there any comprehensive list of changes. I found a small list of highlights on the freebsd.org page, but looking for a dev log or something that I can use in conjunction with examining the source code. Any pointers would be great? Thanks, Yousef From owner-freebsd-arch@FreeBSD.ORG Tue Aug 2 04:05:29 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D098916A420 for ; Tue, 2 Aug 2005 04:05:29 +0000 (GMT) (envelope-from yourabi@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 312FE43D48 for ; Tue, 2 Aug 2005 04:05:29 +0000 (GMT) (envelope-from yourabi@gmail.com) Received: by wproxy.gmail.com with SMTP id i12so1118203wra for ; Mon, 01 Aug 2005 21:05:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=W8ZQzpQ273gaRrVOJt8b2gxReEFOINTSnwTm37FOSvtr/IryBlijNI2x683n0kZvX4g9aIuxJdvSxLRA8Waybs6vlRlT+wTwlQU9EoSrY+pUMs2MgVccXWdxGOugKhTutf9aoQwX4BXcppTt6Kq4qJvVM+1cQcNEtYSA2zSEwZk= Received: by 10.54.43.11 with SMTP id q11mr3477714wrq; Mon, 01 Aug 2005 21:05:27 -0700 (PDT) Received: by 10.54.14.44 with HTTP; Mon, 1 Aug 2005 21:05:27 -0700 (PDT) Message-ID: Date: Mon, 1 Aug 2005 21:05:27 -0700 From: Yousef Ourabi To: arch@freebsd.org, freebsd-arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: 6.0 TCP/IP Stack and Threading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Yousef Ourabi List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 04:05:29 -0000 Hello: I am interested in the changes to the tcp/ip and KSE / scheduler implementation in freebsd 6.0, from the 5.x branch. Is there any comprehensive list of changes. I found a small list of highlights on the freebsd.org page, but looking for a dev log or something that I can use in conjunction with examining the source code. Any pointers would be great? Thanks, Yousef From owner-freebsd-arch@FreeBSD.ORG Tue Aug 2 04:25:21 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B61C216A41F; Tue, 2 Aug 2005 04:25:21 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BF9343D45; Tue, 2 Aug 2005 04:25:21 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j724PKNV030637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Aug 2005 00:25:20 -0400 Received: from obsecurity.dyndns.org (fields.fields.utoronto.ca [128.100.216.11]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j724PJ6P003459; Tue, 2 Aug 2005 00:25:19 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 0E320511CD; Tue, 2 Aug 2005 00:25:11 -0400 (EDT) Date: Tue, 2 Aug 2005 00:25:10 -0400 From: Kris Kennaway To: Yousef Ourabi Message-ID: <20050802042510.GA90360@xor.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: 6.0 TCP/IP Stack and Threading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 04:25:21 -0000 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 01, 2005 at 09:05:27PM -0700, Yousef Ourabi wrote: > Hello: > I am interested in the changes to the tcp/ip and KSE / scheduler > implementation in freebsd 6.0, from the 5.x branch. Is there any > comprehensive list of changes. I found a small list of highlights on > the freebsd.org page, but looking for a dev log or something that I > can use in conjunction with examining the source code. >=20 > Any pointers would be great? You can review the full list of changes through http://cvsweb.freebsd.org. Kris --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC7vWmWry0BWjoQKURApW9AJ9T+/BQkt8Jd3i4K62eqaa5GeayfgCcCyfb /ds2kzLKRbP0x08qTzWB2CQ= =BXlj -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- From owner-freebsd-arch@FreeBSD.ORG Tue Aug 2 04:25:21 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B61C216A41F; Tue, 2 Aug 2005 04:25:21 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BF9343D45; Tue, 2 Aug 2005 04:25:21 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j724PKNV030637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Aug 2005 00:25:20 -0400 Received: from obsecurity.dyndns.org (fields.fields.utoronto.ca [128.100.216.11]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j724PJ6P003459; Tue, 2 Aug 2005 00:25:19 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 0E320511CD; Tue, 2 Aug 2005 00:25:11 -0400 (EDT) Date: Tue, 2 Aug 2005 00:25:10 -0400 From: Kris Kennaway To: Yousef Ourabi Message-ID: <20050802042510.GA90360@xor.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: 6.0 TCP/IP Stack and Threading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 04:25:21 -0000 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 01, 2005 at 09:05:27PM -0700, Yousef Ourabi wrote: > Hello: > I am interested in the changes to the tcp/ip and KSE / scheduler > implementation in freebsd 6.0, from the 5.x branch. Is there any > comprehensive list of changes. I found a small list of highlights on > the freebsd.org page, but looking for a dev log or something that I > can use in conjunction with examining the source code. >=20 > Any pointers would be great? You can review the full list of changes through http://cvsweb.freebsd.org. Kris --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC7vWmWry0BWjoQKURApW9AJ9T+/BQkt8Jd3i4K62eqaa5GeayfgCcCyfb /ds2kzLKRbP0x08qTzWB2CQ= =BXlj -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- From owner-freebsd-arch@FreeBSD.ORG Mon Aug 1 19:55:44 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBFBD16A41F; Mon, 1 Aug 2005 19:55:44 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F18D43D45; Mon, 1 Aug 2005 19:55:43 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from beatrix.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226]) by aiolos.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j71JteVE020293; Mon, 1 Aug 2005 22:55:41 +0300 Received: from beatrix.daedalusnetworks.priv (localhost [127.0.0.1]) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3) with ESMTP id j71Jte7q001422; Mon, 1 Aug 2005 22:55:40 +0300 (EEST) Received: (from keramida@localhost) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3/Submit) id j71JtdwJ001421; Mon, 1 Aug 2005 22:55:39 +0300 (EEST) Date: Mon, 1 Aug 2005 22:55:39 +0300 From: Giorgos Keramidas To: Xin LI Message-ID: <20050801195539.GB1406@beatrix.daedalusnetworks.priv> References: <20050801182518.GA85423@frontfree.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050801182518.GA85423@frontfree.net> X-Mailman-Approved-At: Tue, 02 Aug 2005 11:42:32 +0000 Cc: freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 19:55:45 -0000 On 2005-08-02 02:25, Xin LI wrote: > Hi, Guys, > > Here is a patchset that I have produced to make our libc aware of the > NetBSD assembly implementation of the string related operations. I can't speak for the asm code, since I know barely enough amd64 things to read it, but there are a few typos you might want to fix before this gets committed. > + /* > + * Align to word boundry > + * Consider unrolling loop? s/boundry/boundary/ > + * (1) ~(((x & 0x7f....7f) + 0x7f....7f) | (x | 0x7f....7f)) > + * > + * evaluates to a non-zero value if any of the bytes in the > + * original word is zero. > + * > + * It also has the useful property that bytes in the result word > + * that coorespond to non-zero bytes in the original word have > + * the value 0x00, while bytes cooresponding to zero bytes have s/coorespond/correspond/ in the 2 last lines. > + * On little endian machines, the first byte in the result word > + * that cooresponds to a zero byte in the original byte is 0x80, Ditto. > + * so clz() can be used as above. On big endian machines, and > + * little endian machines without (or with a slow) clz() insn, > + * testing each byte in the original for zero is necessary Missing final period. > + testq $7,%rdx # copy first group of 1 to 7 words > + jz L2 # while swaping alternate bytes. s/swaping/swapping/ That's all I could spot. From owner-freebsd-arch@FreeBSD.ORG Mon Aug 1 20:05:56 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99C1516A41F; Mon, 1 Aug 2005 20:05:56 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51A0A43D48; Mon, 1 Aug 2005 20:05:55 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.4/8.13.4) with ESMTP id j71K5q1X013169; Mon, 1 Aug 2005 13:05:52 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id j71K5quH013168; Mon, 1 Aug 2005 13:05:52 -0700 (PDT) (envelope-from sgk) Date: Mon, 1 Aug 2005 13:05:52 -0700 From: Steve Kargl To: Giorgos Keramidas Message-ID: <20050801200552.GA13041@troutmask.apl.washington.edu> References: <20050801182518.GA85423@frontfree.net> <20050801195539.GB1406@beatrix.daedalusnetworks.priv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050801195539.GB1406@beatrix.daedalusnetworks.priv> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Tue, 02 Aug 2005 11:42:32 +0000 Cc: freebsd-arch@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 20:05:56 -0000 On Mon, Aug 01, 2005 at 10:55:39PM +0300, Giorgos Keramidas wrote: > On 2005-08-02 02:25, Xin LI wrote: > > Hi, Guys, > > > > Here is a patchset that I have produced to make our libc aware of the > > NetBSD assembly implementation of the string related operations. > > I can't speak for the asm code, since I know barely enough amd64 things > to read it, but there are a few typos you might want to fix before this > gets committed. > Ditto. > > That's all I could spot. > There is an occurrence of "occurance", which should be "occurrence". :-) -- Steve From owner-freebsd-arch@FreeBSD.ORG Tue Aug 2 03:17:03 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E578F16A41F; Tue, 2 Aug 2005 03:17:03 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E7C143D48; Tue, 2 Aug 2005 03:17:03 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 5F8CCEB4ABA; Tue, 2 Aug 2005 11:17:01 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id BF87C136E0F; Tue, 2 Aug 2005 11:16:58 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03769-04; Tue, 2 Aug 2005 11:16:51 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 9F57B1366D5; Tue, 2 Aug 2005 11:16:50 +0800 (CST) Date: Tue, 2 Aug 2005 11:16:50 +0800 From: Xin LI To: Giorgos Keramidas Message-ID: <20050802031650.GA3799@frontfree.net> References: <20050801182518.GA85423@frontfree.net> <20050801195539.GB1406@beatrix.daedalusnetworks.priv> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline In-Reply-To: <20050801195539.GB1406@beatrix.daedalusnetworks.priv> User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.4-RELEASE-p6 FreeBSD 5.4-RELEASE-p6 #4: Thu Jul 28 10:59:26 CST 2005 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: amavisd-new at frontfree.net X-Mailman-Approved-At: Tue, 02 Aug 2005 11:42:32 +0000 Cc: freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 03:17:04 -0000 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Giorgos, On Mon, Aug 01, 2005 at 10:55:39PM +0300, Giorgos Keramidas wrote: > On 2005-08-02 02:25, Xin LI wrote: > > Hi, Guys, > > > > Here is a patchset that I have produced to make our libc aware of the > > NetBSD assembly implementation of the string related operations. >=20 > I can't speak for the asm code, since I know barely enough amd64 things > to read it, but there are a few typos you might want to fix before this > gets committed. [good stuff snipped] > That's all I could spot. Thanks very much, will do more proof reading before considering to commit it :-) Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC7uWi/cVsHxFZiIoRArPPAJ9zPkW434Tg9Ygr83p1RDzthJThdwCdFngr T0trij/cWiEOyjpy8di4WUY= =bA1+ -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH-- From owner-freebsd-arch@FreeBSD.ORG Tue Aug 2 16:41:37 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6875416A41F; Tue, 2 Aug 2005 16:41:37 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id B855243D45; Tue, 2 Aug 2005 16:41:36 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 14CA8EB4B16; Wed, 3 Aug 2005 00:41:33 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 1CD2C1384F6; Wed, 3 Aug 2005 00:41:30 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16558-08; Wed, 3 Aug 2005 00:41:21 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 6AD8F1384E5; Wed, 3 Aug 2005 00:41:20 +0800 (CST) Date: Wed, 3 Aug 2005 00:41:20 +0800 From: Xin LI To: freebsd-arch@FreeBSD.org, freebsd-amd64@FreeBSD.org Message-ID: <20050802164120.GA16775@frontfree.net> References: <20050801182518.GA85423@frontfree.net> <20050802013916.GA37135@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XF85m9dhOBO43t/C" Content-Disposition: inline In-Reply-To: <20050802013916.GA37135@dragon.NUXI.org> User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.4-RELEASE-p6 FreeBSD 5.4-RELEASE-p6 #4: Thu Jul 28 10:59:26 CST 2005 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: amavisd-new at frontfree.net Cc: Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 16:41:37 -0000 --XF85m9dhOBO43t/C Content-Type: multipart/mixed; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 01, 2005 at 06:39:16PM -0700, David O'Brien wrote: > On Tue, Aug 02, 2005 at 02:25:18AM +0800, Xin LI wrote: > > Here is a patchset that I have produced to make our libc aware of the > > NetBSD assembly implementation of the string related operations. >=20 > What performance benchmarks have these been thru? In summary: index, rindex, memchr, strchr, strlen, strlen, strrchr are faster than their C counterparts; ffs, strncmp are about the same, and swab is worse. Note that these tests are done within loops that first copy a string to a new place, then perform the operation, then free the string, to defeat cache effects. The attachement has provided some details. If anyone wants the (ugly) test code, please let me know. Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=result-x86_64vsC BETTER CASES [delphij@warrior7] ~/test/index> /usr/bin/time ./index 5.81 real 5.79 user 0.00 sys ASSEMBLY 1.84 real 1.82 user 0.00 sys [delphij@warrior7] ~/test/rindex> /usr/bin/time ./rindex 6.25 real 6.24 user 0.00 sys ASSEMBLY 2.17 real 1.84 user 0.01 sys [delphij@warrior7] ~/test/memchr> /usr/bin/time ./memchr 5.93 real 5.91 user 0.00 sys ASSEMBLY 1.91 real 1.84 user 0.00 sys [delphij@warrior7] ~/test/strchr> /usr/bin/time ./strchr 5.93 real 5.91 user 0.00 sys ASSEMBLY 1.84 real 1.83 user 0.00 sys [delphij@warrior7] ~/test/strlen> /usr/bin/time ./strlen 7.13 real 7.12 user 0.00 sys ASSEMBLY 1.44 real 1.43 user 0.00 sys [delphij@warrior7] ~/test/strrchr> /usr/bin/time ./strrchr 9.12 real 9.08 user 0.00 sys ASSEMBLY 4.71 real 4.69 user 0.00 sys WORSE/NO EFFECTS [delphij@warrior7] ~/test/ffs> /usr/bin/time ./ffs 0.33 real 0.33 user 0.00 sys ASSEMBLY 0.33 real 0.33 user 0.00 sys [delphij@warrior7] ~/test/strncmp> /usr/bin/time ./strncmp 3.90 real 3.88 user 0.00 sys 3.88 real 3.87 user 0.00 sys ASSEMBLY 3.88 real 3.87 user 0.00 sys [delphij@warrior7] ~/test/swab> /usr/bin/time ./swab 6.59 real 6.53 user 0.01 sys ASSEMBLY 8.06 real 8.05 user 0.00 sys --CE+1k2dSO48ffgeK-- --XF85m9dhOBO43t/C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC76Iw/cVsHxFZiIoRAm7dAJ9c9OXtEXP50o7LGwQu4LeehGzK2QCfa41T kNaVpPLdVEsHuZwlXoufgjY= =no2E -----END PGP SIGNATURE----- --XF85m9dhOBO43t/C-- From owner-freebsd-arch@FreeBSD.ORG Tue Aug 2 17:20:44 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1E1516A41F; Tue, 2 Aug 2005 17:20:44 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4472343D45; Tue, 2 Aug 2005 17:20:44 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j72HKgdZ085112; Tue, 2 Aug 2005 10:20:42 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j72HKgmu085111; Tue, 2 Aug 2005 10:20:42 -0700 (PDT) (envelope-from obrien) Date: Tue, 2 Aug 2005 10:20:42 -0700 From: "David O'Brien" To: Xin LI Message-ID: <20050802172042.GA71672@dragon.NUXI.org> Mail-Followup-To: freebsd-arch@FreeBSD.org, freebsd-amd64@FreeBSD.org, Xin LI References: <20050801182518.GA85423@frontfree.net> <20050802013916.GA37135@dragon.NUXI.org> <20050802040246.GB3799@frontfree.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050802040246.GB3799@frontfree.net> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-arch@FreeBSD.org, freebsd-amd64@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 17:20:44 -0000 On Tue, Aug 02, 2005 at 12:02:46PM +0800, Xin LI wrote: > On Mon, Aug 01, 2005 at 06:39:16PM -0700, David O'Brien wrote: > > On Tue, Aug 02, 2005 at 02:25:18AM +0800, Xin LI wrote: > > > Here is a patchset that I have produced to make our libc aware of the > > > NetBSD assembly implementation of the string related operations. > > > > What performance benchmarks have these been thru? .. > BTW. Would you please give me some hints on the benchmarking? I am > not sure whether just looping the test cases on some determine dataset > would be enough? Try some real world tests such as 'make buildworld'. Looking in src/usr.bin the following utils make good use of these libc functions and would be good real world tests: uuencode catman compress last makewhatis * uuencode a large kernel * run /etc/periodic/weekly/320.whatis * compress a large kernel * last delphij on a large /var/log/wtmp * cp /usr/src/share/man/man[1-9] to a ram disk and then run catman over it Just a few suggestions. It is easy to "optimize" for the simple input case and miss the larger case. I've also seen people "optimize" for all cases but then wind up with so much overhead that small inputs are slower. I have some very fancy routines from AMD that take into account cache size, alignment, and uses the prefetch instructions. The problem is they are a huge win for large input sizes, but I'm concerned about their performance on small input sizes. If these NetBSD routines perform better in the tests I listed above, we should commit them. We can continue to refine these libc routines over time. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Tue Aug 2 17:36:07 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B271716A429; Tue, 2 Aug 2005 17:36:07 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id D53B043D48; Tue, 2 Aug 2005 17:36:06 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id A7F73EB3FCC; Wed, 3 Aug 2005 01:36:04 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 65EF113435F; Wed, 3 Aug 2005 01:36:01 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17150-14; Wed, 3 Aug 2005 01:35:53 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 63E31133D09; Wed, 3 Aug 2005 01:35:52 +0800 (CST) Date: Wed, 3 Aug 2005 01:35:52 +0800 From: Xin LI To: freebsd-arch@FreeBSD.org, freebsd-amd64@FreeBSD.org Message-ID: <20050802173552.GB17471@frontfree.net> References: <20050801182518.GA85423@frontfree.net> <20050802013916.GA37135@dragon.NUXI.org> <20050802040246.GB3799@frontfree.net> <20050802172042.GA71672@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/WwmFnJnmDyWGHa4" Content-Disposition: inline In-Reply-To: <20050802172042.GA71672@dragon.NUXI.org> User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.4-RELEASE-p6 FreeBSD 5.4-RELEASE-p6 #4: Thu Jul 28 10:59:26 CST 2005 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: amavisd-new at frontfree.net Cc: Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 17:36:07 -0000 --/WwmFnJnmDyWGHa4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 02, 2005 at 10:20:42AM -0700, David O'Brien wrote: > On Tue, Aug 02, 2005 at 12:02:46PM +0800, Xin LI wrote: > > On Mon, Aug 01, 2005 at 06:39:16PM -0700, David O'Brien wrote: > > > On Tue, Aug 02, 2005 at 02:25:18AM +0800, Xin LI wrote: > > > > Here is a patchset that I have produced to make our libc aware of t= he > > > > NetBSD assembly implementation of the string related operations. > > >=20 > > > What performance benchmarks have these been thru? > .. > > BTW. Would you please give me some hints on the benchmarking? I am > > not sure whether just looping the test cases on some determine dataset > > would be enough? >=20 > Try some real world tests such as 'make buildworld'. Looking in > src/usr.bin the following utils make good use of these libc functions and > would be good real world tests: uuencode catman compress last makewhatis >=20 > * uuencode a large kernel > * run /etc/periodic/weekly/320.whatis > * compress a large kernel > * last delphij on a large /var/log/wtmp > * cp /usr/src/share/man/man[1-9] to a ram disk and then run catman over it Thanks, I will try these tomorrow. > Just a few suggestions. It is easy to "optimize" for the simple input ca= se > and miss the larger case. I've also seen people "optimize" for all cases > but then wind up with so much overhead that small inputs are slower. >=20 > I have some very fancy routines from AMD that take into account cache > size, alignment, and uses the prefetch instructions. The problem is they > are a huge win for large input sizes, but I'm concerned about their > performance on small input sizes. >=20 > If these NetBSD routines perform better in the tests I listed above, we > should commit them. We can continue to refine these libc routines over > time. Agreed. I will do more careful benchmarks that can reflect more real world= =20 better, to figure out whether these "optimizations" are really necessary for us. Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --/WwmFnJnmDyWGHa4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC7674/cVsHxFZiIoRAu/4AJ9w62vonIN+p9sfcdZZNJcuOkSsHgCcDpci 5psIn9+yVcxR0DVnB248410= =beKZ -----END PGP SIGNATURE----- --/WwmFnJnmDyWGHa4-- From owner-freebsd-arch@FreeBSD.ORG Tue Aug 2 14:29:07 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EFFD16A447 for ; Tue, 2 Aug 2005 14:29:07 +0000 (GMT) (envelope-from rpaulo@NetBSD.org) Received: from pluricanal.net (mail.pluricanal.net [83.144.129.196]) by mx1.FreeBSD.org (Postfix) with SMTP id DE0CF43D48 for ; Tue, 2 Aug 2005 14:29:05 +0000 (GMT) (envelope-from rpaulo@NetBSD.org) Received: (qmail 26436 invoked from network); 2 Aug 2005 16:22:00 -0000 Received: from unknown (HELO proton.internal.fnop.net) (83.144.140.19) by mail.pluricanal.net with SMTP; 2 Aug 2005 16:22:00 -0000 Received: by proton.internal.fnop.net (Postfix, from userid 1000) id 2AD013307; Tue, 2 Aug 2005 15:27:22 +0100 (WEST) Date: Tue, 2 Aug 2005 15:27:22 +0100 From: Rui Paulo To: Steve Kargl Message-ID: <20050802142722.GA2583@proton.internal.fnop.net> References: <20050801182518.GA85423@frontfree.net> <20050801195539.GB1406@beatrix.daedalusnetworks.priv> <20050801200552.GA13041@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050801200552.GA13041@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Wed, 03 Aug 2005 11:43:20 +0000 Cc: freebsd-amd64@freebsd.org, Giorgos Keramidas , freebsd-arch@freebsd.org Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 14:29:07 -0000 On 2005.08.01 13:05:52 +0000, Steve Kargl wrote: | On Mon, Aug 01, 2005 at 10:55:39PM +0300, Giorgos Keramidas wrote: | > On 2005-08-02 02:25, Xin LI wrote: | > > Hi, Guys, | > > | > > Here is a patchset that I have produced to make our libc aware of the | > > NetBSD assembly implementation of the string related operations. | > | > I can't speak for the asm code, since I know barely enough amd64 things | > to read it, but there are a few typos you might want to fix before this | > gets committed. | > | | Ditto. | | > | > That's all I could spot. | > | | There is an occurrence of "occurance", which should be "occurrence". :-) Thank you Steve Kargl and Giorgos Keramidas, I fixed those typos on NetBSD. http://mail-index.netbsd.org/source-changes/2005/08/02/0009.html http://mail-index.netbsd.org/source-changes/2005/08/02/0010.html -- Rui Paulo From owner-freebsd-arch@FreeBSD.ORG Wed Aug 3 20:01:49 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93A8116A41F for ; Wed, 3 Aug 2005 20:01:49 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5E7043D46 for ; Wed, 3 Aug 2005 20:01:48 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from c-66-30-115-133.hsd1.ma.comcast.net ([66.30.115.133]) by comcast.net (sccrmhc12) with ESMTP id <2005080320014301200pbujce>; Wed, 3 Aug 2005 20:01:45 +0000 Received: from c-66-30-115-133.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by c-66-30-115-133.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id j73K1hiZ070809 for ; Wed, 3 Aug 2005 16:01:43 -0400 (EDT) (envelope-from rodrigc@c-66-30-115-133.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-115-133.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id j73K1heB070808 for freebsd-arch@freebsd.org; Wed, 3 Aug 2005 16:01:43 -0400 (EDT) (envelope-from rodrigc) Date: Wed, 3 Aug 2005 16:01:43 -0400 From: Craig Rodrigues To: freebsd-arch@freebsd.org Message-ID: <20050803200143.GA70735@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Subject: [RFC] Kernel patches for compilation with gcc 4.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2005 20:01:49 -0000 Hi, I installed gcc version 4.0.2 20050721 (prerelease) [FreeBSD] from ports and tried to compile the kernel using a LINT config file on i386. I had to apply these patches: http://people.freebsd.org/~rodrigc/fbsd.makefiles.diff.txt to the kernel makefile rules because "-I-" is removed from gcc 4.0, and "-fformat-extensions" is a FreeBSD extension to GCC which is not in the ports version of the compiler. I had to apply these patches to the source code to eliminate errors: http://people.freebsd.org/~rodrigc/fbsd.kernel.gcc40.diffs.txt Mostly I fixed cases like this: extern struct foo bar; static struct foo bar = { }; In ISO C, it is illegal to define a struct with external linkage, and then internal linkage. GCC 3.x allows it, but GCC 4.x flags it as an error. Also, if you do: static struct foo bar; static struct foo bar = { }; then the -Wredundant-decls flag in the kernel makefile will issue a warning. Can someone provide feedback on the kernel patches? Thanks. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-arch@FreeBSD.ORG Wed Aug 3 23:05:44 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BCD216A41F; Wed, 3 Aug 2005 23:05:44 +0000 (GMT) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id C76B643D46; Wed, 3 Aug 2005 23:05:43 +0000 (GMT) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.12.11/jtpda-5.4) with ESMTP id j73N5gcg000335 ; Thu, 4 Aug 2005 01:05:42 +0200 (CEST) X-Ids: 168 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id j73N5ebj008434 ; Thu, 4 Aug 2005 01:05:40 +0200 (MEST) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.13.3/8.13.1/Submit) id j73N5eoM008431; Thu, 4 Aug 2005 01:05:40 +0200 (MEST) (envelope-from arno) To: Doug Barton References: <53d4293a37f280317d52338c2fc6fc6d@FreeBSD.org> <20050612025402.GD67746@dragon.NUXI.org> <200506151655.52894.jhb@FreeBSD.org> <20050616010629.GA3554@hub.freebsd.org> <42EEC3B9.1090507@FreeBSD.org> From: "Arno J. Klaassen" Date: 04 Aug 2005 01:05:40 +0200 In-Reply-To: <42EEC3B9.1090507@FreeBSD.org> Message-ID: Lines: 46 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.2 (shiva.jussieu.fr [134.157.0.168]); Thu, 04 Aug 2005 01:05:42 +0200 (CEST) X-Antivirus: scanned by sophie at shiva.jussieu.fr X-Miltered: at shiva.jussieu.fr with ID 42F14DC6.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Cc: freebsd-arch@freebsd.org Subject: Re: Death to toor X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2005 23:05:44 -0000 Doug Barton writes: > Arno J. Klaassen wrote: > > Hello, > > [ stuff deleted ] > > > >>>>>Is there any good reason to keep the toor account around nowadays? > >>>> > >>>>Yes. Some of us use it. > > from a user point of view, I use toor on all machines, basically for > > two reasons : > > - I don't feel confident to change default root shell > > As long as you change it to another shell that is provided by the > system (in this case /bin/sh) you'll be fine here. I've done this for > years. My .profile tests to see if bash is available, and execs it if > so. yop, i did it that way before; but I got tired of all tests in .profile, .bash_profile, .bashrc (mixing gdm and ssh on the same box gives me the same headaches of not taking the time to figure out exactly which shell uses what file, in what order and overruled by what environment ...) > Note, I'm not saying that we should get rid of toor, quite the > opposite, I think we should keep it. me too, but in that case including /bin/bash in the base-system would be a nice thing as well, or at least a shells/bash-root port or something like that. my first thing on each new installation is statically build shells/bash and copy to /bin > > - quite a lot of my customors "need/want" root access (including the > > possibility to change it's passwd); keeping a toor account with a well > > kept secret by me passwd saves me a lot of trouble (a part from > > systems needing root passwd for catastrophic single user boot) > > That's an entirely different situation. yes, but imho a good reason to keep the toor account at least mentionned in the base system. I'm still glad my mentor explained me X years ago its existence. Naturally a newbie sysadmin thinks there is just one and only root. Arno From owner-freebsd-arch@FreeBSD.ORG Wed Aug 3 23:09:26 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E550716A41F for ; Wed, 3 Aug 2005 23:09:26 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail1.fluidhosting.com (mail1.fluidhosting.com [204.14.90.61]) by mx1.FreeBSD.org (Postfix) with SMTP id 0A14543D68 for ; Wed, 3 Aug 2005 23:09:19 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 99344 invoked by uid 399); 3 Aug 2005 23:09:17 -0000 Received: from mail1.fluidhosting.com (66.150.201.101) by mail1.fluidhosting.com with SMTP; 3 Aug 2005 23:09:17 -0000 Received: (qmail 7896 invoked by uid 399); 3 Aug 2005 23:09:14 -0000 Received: from unknown (HELO ?192.168.1.101?) (dougb@dougbarton.net@69.175.228.47) by mail1.fluidhosting.com with SMTP; 3 Aug 2005 23:09:14 -0000 Message-ID: <42F14E99.8@FreeBSD.org> Date: Wed, 03 Aug 2005 16:09:13 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050726) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Arno J. Klaassen" References: <53d4293a37f280317d52338c2fc6fc6d@FreeBSD.org> <20050612025402.GD67746@dragon.NUXI.org> <200506151655.52894.jhb@FreeBSD.org> <20050616010629.GA3554@hub.freebsd.org> <42EEC3B9.1090507@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Death to toor X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2005 23:09:27 -0000 Arno J. Klaassen wrote: > yop, i did it that way before; but I got tired of all tests in .profile, > .bash_profile, .bashrc (mixing gdm and ssh on the same box gives me > the same headaches of not taking the time to figure out exactly which > shell uses what file, in what order and overruled by what environment ...) Well, I can't help you there. > including /bin/bash in the base-system would > be a nice thing as well There is extensive discussion in the archives about why this is incredibly unlikely to happen, so I wouldn't hold your breath. Doug -- This .signature sanitized for your protection From owner-freebsd-arch@FreeBSD.ORG Wed Aug 3 15:31:52 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDD0016A41F for ; Wed, 3 Aug 2005 15:31:52 +0000 (GMT) (envelope-from rnsanchez@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id D534C43D4C for ; Wed, 3 Aug 2005 15:31:51 +0000 (GMT) (envelope-from rnsanchez@gmail.com) Received: by wproxy.gmail.com with SMTP id i22so168565wra for ; Wed, 03 Aug 2005 08:31:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=q1gTbT+7gYinFRUf2OI12Iebf8aD9ke1NDGFxDyrDPyJ32zV+wTIaneiRPSxdnkTp844Z9Zxf4T16AHTuktGrs1vUce3PCqicpdMd+y34ejKRTtlTir0HqA8mOvFwiPugic6kcDtl0B3CGB9jiygMAA+HRsl3bWpQ0JdlUo+Zt8= Received: by 10.54.13.77 with SMTP id 77mr689353wrm; Wed, 03 Aug 2005 08:31:51 -0700 (PDT) Received: by 10.54.38.8 with HTTP; Wed, 3 Aug 2005 08:31:50 -0700 (PDT) Message-ID: <52b3de6f0508030831f2995ba@mail.gmail.com> Date: Wed, 3 Aug 2005 12:31:50 -0300 From: Ricardo Nabinger Sanchez To: Rui Paulo In-Reply-To: <20050802142722.GA2583@proton.internal.fnop.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050801182518.GA85423@frontfree.net> <20050801195539.GB1406@beatrix.daedalusnetworks.priv> <20050801200552.GA13041@troutmask.apl.washington.edu> <20050802142722.GA2583@proton.internal.fnop.net> X-Mailman-Approved-At: Thu, 04 Aug 2005 11:51:31 +0000 Cc: Giorgos Keramidas , freebsd-amd64@freebsd.org, Steve Kargl , freebsd-arch@freebsd.org Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2005 15:31:53 -0000 Hello, On 8/2/05, Rui Paulo wrote: > On 2005.08.01 13:05:52 +0000, Steve Kargl wrote: > | On Mon, Aug 01, 2005 at 10:55:39PM +0300, Giorgos Keramidas wrote: > | > On 2005-08-02 02:25, Xin LI wrote: > | > > Hi, Guys, > | > > > | > > Here is a patchset that I have produced to make our libc aware of t= he > | > > NetBSD assembly implementation of the string related operations. > | > > | > I can't speak for the asm code, since I know barely enough amd64 thin= gs > | > to read it, but there are a few typos you might want to fix before th= is > | > gets committed. > | > > | > | Ditto. > | > | > > | > That's all I could spot. > | > > | > | There is an occurrence of "occurance", which should be "occurrence". :-= ) >=20 > Thank you Steve Kargl and Giorgos Keramidas, I fixed those typos on NetBS= D. >=20 > http://mail-index.netbsd.org/source-changes/2005/08/02/0009.html > http://mail-index.netbsd.org/source-changes/2005/08/02/0010.html There's also this one: +L3:=09movzbl=09(%rdi),%eax=09=09/* unsigned comparision */ s/comparision/comparison --=20 Ricardo Nabinger Sanchez GNU/Linux #140696 [http://counter.li.org] Slackware Linux + FreeBSD From owner-freebsd-arch@FreeBSD.ORG Wed Aug 3 23:02:34 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B2C716A420 for ; Wed, 3 Aug 2005 23:02:34 +0000 (GMT) (envelope-from rpaulo@NetBSD.org) Received: from pluricanal.net (mail.pluricanal.net [83.144.129.196]) by mx1.FreeBSD.org (Postfix) with SMTP id 1A30343D4C for ; Wed, 3 Aug 2005 23:02:32 +0000 (GMT) (envelope-from rpaulo@NetBSD.org) Received: (qmail 5358 invoked from network); 4 Aug 2005 00:53:50 -0000 Received: from unknown (HELO proton.internal.fnop.net) (83.144.140.19) by mail.pluricanal.net with SMTP; 4 Aug 2005 00:53:50 -0000 Received: by proton.internal.fnop.net (Postfix, from userid 1000) id C9982330F; Wed, 3 Aug 2005 23:58:58 +0100 (WEST) Date: Wed, 3 Aug 2005 23:58:58 +0100 From: Rui Paulo To: Ricardo Nabinger Sanchez Message-ID: <20050803225858.GA1180@proton.internal.fnop.net> References: <20050801182518.GA85423@frontfree.net> <20050801195539.GB1406@beatrix.daedalusnetworks.priv> <20050801200552.GA13041@troutmask.apl.washington.edu> <20050802142722.GA2583@proton.internal.fnop.net> <52b3de6f0508030831f2995ba@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52b3de6f0508030831f2995ba@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Thu, 04 Aug 2005 11:51:31 +0000 Cc: Giorgos Keramidas , freebsd-amd64@freebsd.org, Steve Kargl , freebsd-arch@freebsd.org Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2005 23:02:34 -0000 On 2005.08.03 12:31:50 +0000, Ricardo Nabinger Sanchez wrote: | There's also this one: | | +L3: movzbl (%rdi),%eax /* unsigned comparision */ | | s/comparision/comparison Fixed, thanks. -- Rui Paulo From owner-freebsd-arch@FreeBSD.ORG Fri Aug 5 14:49:14 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49C1016A41F for ; Fri, 5 Aug 2005 14:49:14 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id C74C943D46 for ; Fri, 5 Aug 2005 14:49:13 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 05 Aug 2005 11:03:55 -0400 From: John Baldwin To: freebsd-arch@freebsd.org Date: Fri, 5 Aug 2005 10:49:25 -0400 User-Agent: KMail/1.8 References: <20050803200143.GA70735@crodrigues.org> In-Reply-To: <20050803200143.GA70735@crodrigues.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508051049.26158.jhb@FreeBSD.org> Cc: Craig Rodrigues Subject: Re: [RFC] Kernel patches for compilation with gcc 4.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2005 14:49:14 -0000 On Wednesday 03 August 2005 04:01 pm, Craig Rodrigues wrote: > Hi, > > I installed gcc version 4.0.2 20050721 (prerelease) [FreeBSD] > from ports and tried to compile the kernel using a LINT config file on > i386. > > I had to apply these patches: > http://people.freebsd.org/~rodrigc/fbsd.makefiles.diff.txt > > to the kernel makefile rules because "-I-" is removed from gcc 4.0, > and "-fformat-extensions" is a FreeBSD extension to GCC which is not > in the ports version of the compiler. > > I had to apply these patches to the source code to eliminate errors: > > http://people.freebsd.org/~rodrigc/fbsd.kernel.gcc40.diffs.txt > > Mostly I fixed cases like this: > > extern struct foo bar; > static struct foo bar = { }; > > In ISO C, it is illegal to define a struct with external linkage, > and then internal linkage. GCC 3.x allows it, but GCC 4.x flags it as an > error. > > Also, if you do: > static struct foo bar; > static struct foo bar = { }; > > then the -Wredundant-decls flag in the kernel makefile will issue > a warning. > > Can someone provide feedback on the kernel patches? > Thanks. It would be really nice to not have to add a bunch of (caddr_t) casts. You need to get the acpi_wakeup changes reviewed. Not saving the gdt and idt descriptors across suspend/resume would be very disastrous. I think it is a mistake to make static structures like th0 non-static to workaround -Wredundant-decls. Get gcc to fix -Wredundant-decls instead if at all possible. kern_tc.c is an example of this type of change. rtsock.c probably is, too. Why did you move MALLOC_DECLARE out of in6_var.h? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Fri Aug 5 16:22:34 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECB8D16A41F; Fri, 5 Aug 2005 16:22:34 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.202.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id E35BB43D46; Fri, 5 Aug 2005 16:22:33 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from c-66-30-115-133.hsd1.ma.comcast.net ([66.30.115.133]) by comcast.net (sccrmhc14) with ESMTP id <2005080516223201400d1ei4e>; Fri, 5 Aug 2005 16:22:32 +0000 Received: from c-66-30-115-133.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by c-66-30-115-133.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id j75GMYU4097344; Fri, 5 Aug 2005 12:22:34 -0400 (EDT) (envelope-from rodrigc@c-66-30-115-133.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-115-133.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id j75GMYUo097343; Fri, 5 Aug 2005 12:22:34 -0400 (EDT) (envelope-from rodrigc) Date: Fri, 5 Aug 2005 12:22:34 -0400 From: Craig Rodrigues To: John Baldwin Message-ID: <20050805162234.GA96585@crodrigues.org> References: <20050803200143.GA70735@crodrigues.org> <200508051049.26158.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200508051049.26158.jhb@FreeBSD.org> User-Agent: Mutt/1.5.9i Cc: freebsd-arch@FreeBSD.org Subject: Re: [RFC] Kernel patches for compilation with gcc 4.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2005 16:22:35 -0000 On Fri, Aug 05, 2005 at 10:49:25AM -0400, John Baldwin wrote: > You need to get the acpi_wakeup changes reviewed. Not saving the gdt and idt > descriptors across suspend/resume would be very disastrous. I sent a separate e-mail to njl@ and marks@ about the acpi_wakeup patch. The patch was suggested to me by kan@. He suggested that I remove the static variables which clashed with the global variables of the same name, and to remove asm calls which saved them in acpi_wakeup.c > I think it is a mistake to make static structures like th0 non-static to > workaround -Wredundant-decls. Get gcc to fix -Wredundant-decls instead if at > all possible. kern_tc.c is an example of this type of change. rtsock.c > probably is, too. This behavior in GCC seems to have been there for a long time (I can reproduce it with 2.95, 3.4, and 4.0). I can ask the GCC people about this. The other alternative is to remove -Wredundant-decls from the kernel Makefiles. I asked why we use -Wredundant-decls, because it seems to warn against legal C code: http://lists.freebsd.org/pipermail/freebsd-current/2005-August/053708.html I'm not enough of a C guru to know.... > Why did you move MALLOC_DECLARE out of in6_var.h? Because I got this compiler error in in.c : gcc40 -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -std=c99 -g -nostdinc -I. -I../../.. -I../../../contrib/dev/acpica -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contrib/pf -I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd -I../../../contrib/ngatm -I../../../dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror ../../../netinet/in.c ../../../netinet/in.c:54: error: static declaration of 'M_IPMADDR' follows non-static declaration ../../../netinet6/in6_var.h:479: error: previous declaration of 'M_IPMADDR' was here *** Error code 1 -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-arch@FreeBSD.ORG Fri Aug 5 17:06:50 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C3DF16A41F for ; Fri, 5 Aug 2005 17:06:50 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9708543D46 for ; Fri, 5 Aug 2005 17:06:49 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 05 Aug 2005 13:21:30 -0400 From: John Baldwin To: freebsd-arch@freebsd.org Date: Fri, 5 Aug 2005 13:07:18 -0400 User-Agent: KMail/1.8 References: <20050803200143.GA70735@crodrigues.org> <200508051049.26158.jhb@FreeBSD.org> <20050805162234.GA96585@crodrigues.org> In-Reply-To: <20050805162234.GA96585@crodrigues.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508051307.19261.jhb@FreeBSD.org> Cc: Craig Rodrigues Subject: Re: [RFC] Kernel patches for compilation with gcc 4.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2005 17:06:50 -0000 On Friday 05 August 2005 12:22 pm, Craig Rodrigues wrote: > On Fri, Aug 05, 2005 at 10:49:25AM -0400, John Baldwin wrote: > > You need to get the acpi_wakeup changes reviewed. Not saving the gdt and > > idt descriptors across suspend/resume would be very disastrous. > > I sent a separate e-mail to njl@ and marks@ about the acpi_wakeup patch. > The patch was suggested to me by kan@. He suggested that > I remove the static variables which clashed with the global variables > of the same name, and to remove asm calls which saved them in acpi_wakeup.c Ok. I thought I had recalled something about that but wasn't sure. > > I think it is a mistake to make static structures like th0 non-static to > > workaround -Wredundant-decls. Get gcc to fix -Wredundant-decls instead > > if at all possible. kern_tc.c is an example of this type of change. > > rtsock.c probably is, too. > > This behavior in GCC seems to have been there for a long time > (I can reproduce it with 2.95, 3.4, and 4.0). I can ask the GCC people > about this. The other alternative is to remove -Wredundant-decls > from the kernel Makefiles. I asked why we use -Wredundant-decls, because > it seems to warn against legal C code: > > http://lists.freebsd.org/pipermail/freebsd-current/2005-August/053708.html > > I'm not enough of a C guru to know.... Ok, given that, I'd rather remove -Wredundant_decls than break perfectly legal code. It would be nice if there was a -Wredundant_decls_that_actually_works > > Why did you move MALLOC_DECLARE out of in6_var.h? > > Because I got this compiler error in in.c : > > gcc40 -c -O -pipe -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -std=c99 -g -nostdinc -I. -I../../.. > -I../../../contrib/dev/acpica -I../../../contrib/altq > -I../../../contrib/ipfilter -I../../../contrib/pf > -I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd > -I../../../contrib/ngatm -I../../../dev/twa -D_KERNEL -include opt_global.h > -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -mpreferred-stack-boundary=2 -mno-mmx > -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror > ../../../netinet/in.c ../../../netinet/in.c:54: error: static declaration > of 'M_IPMADDR' follows non-static declaration > ../../../netinet6/in6_var.h:479: error: previous declaration of 'M_IPMADDR' > was here *** Error code 1 Looks like this is indicative of another error. There are two different M_IPMADDR malloc buckets. The IPv6 one should probably be called M_IP6MADDR instead. netinet/in.c:static MALLOC_DEFINE(M_IPMADDR, "in_multi", "internet multicast address"); netinet6/in6.c:MALLOC_DEFINE(M_IPMADDR, "in6_multi", "internet multicast address"); -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Fri Aug 5 17:21:18 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CEC816A41F for ; Fri, 5 Aug 2005 17:21:18 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from viefep20-int.chello.at (viefep12-int.chello.at [213.46.255.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id E047943D58 for ; Fri, 5 Aug 2005 17:21:13 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from wombat.fafoe.narf.at ([213.47.85.26]) by viefep20-int.chello.at (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20050805172111.EVFH25440.viefep20-int.chello.at@wombat.fafoe.narf.at> for ; Fri, 5 Aug 2005 19:21:11 +0200 Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id DE6512C7; Fri, 5 Aug 2005 19:21:10 +0200 (CEST) Date: Fri, 5 Aug 2005 19:21:10 +0200 From: Stefan Farfeleder To: freebsd-arch@freebsd.org Message-ID: <20050805172108.GE632@wombat.fafoe.narf.at> References: <20050803200143.GA70735@crodrigues.org> <200508051049.26158.jhb@FreeBSD.org> <20050805162234.GA96585@crodrigues.org> <200508051307.19261.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200508051307.19261.jhb@FreeBSD.org> User-Agent: Mutt/1.5.9i Subject: Re: [RFC] Kernel patches for compilation with gcc 4.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2005 17:21:18 -0000 On Fri, Aug 05, 2005 at 01:07:18PM -0400, John Baldwin wrote: > > Ok, given that, I'd rather remove -Wredundant_decls than break perfectly legal > code. It would be nice if there was a -Wredundant_decls_that_actually_works Seconded. From owner-freebsd-arch@FreeBSD.ORG Fri Aug 5 18:48:29 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0BCD16A41F for ; Fri, 5 Aug 2005 18:48:29 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id A03E743D48 for ; Fri, 5 Aug 2005 18:48:29 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id E37B3BC66 for ; Fri, 5 Aug 2005 18:48:27 +0000 (UTC) To: arch@freebsd.org From: Poul-Henning Kamp Date: Fri, 05 Aug 2005 20:48:27 +0200 Message-ID: <21744.1123267707@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: Subject: putting HESIOD, Appletalk and IPX on notice X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2005 18:48:30 -0000 I think it is time we deorbit HESIOD in toto. At the same time, making Appletalk and IPX "opt in" facilities by putting them under YES_IPX and YES_APPLETALK boolean build options seems a sensible move. Comments ? The first RELENG_7 release would happen in 2006 or 2007, there is no way they will need any of those three protocols. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Aug 5 19:32:28 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BEB216A41F for ; Fri, 5 Aug 2005 19:32:28 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1332B43D48 for ; Fri, 5 Aug 2005 19:32:25 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j75JWMCX018021; Fri, 5 Aug 2005 15:32:24 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <21744.1123267707@phk.freebsd.dk> References: <21744.1123267707@phk.freebsd.dk> Date: Fri, 5 Aug 2005 15:32:22 -0400 To: Poul-Henning Kamp , arch@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.2 Cc: Subject: Re: putting HESIOD, Appletalk and IPX on notice X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2005 19:32:28 -0000 At 8:48 PM +0200 8/5/05, Poul-Henning Kamp wrote: >I think it is time we deorbit HESIOD in toto. I don't even know what HESIOD is... >At the same time, making Appletalk and IPX "opt in" facilities >by putting them under > YES_IPX I do know what IPX is. It is fine with me if it disappears. >and > YES_APPLETALK >boolean build options seems a sensible move. > >Comments ? > >The first RELENG_7 release would happen in 2006 or 2007, there >is no way they will need any of those three protocols. Appletalk is still in use at RPI for printing-purposes, and it will certainly still be in use in 2006 and very likely 2007. It's only used for talking between print-servers and the printers, and we (RPI) don't route appletalk around our networks as much. But we do still use it and will continue to use it for awhile longer. We printed about 2 million pages via appletalk in the past year, and have no intention of stopping that in the upcoming year. I do not mind if it is made opt-in. (I'm not quite sure what that switch would effect. Netatalk kernel module? Anything else?) I should also admit that I actually use solaris machines for our print servers, so in some sense it doesn't really effect me if freebsd loses appletalk. But before our last reorg, I was going to move all our print servers from Solaris to FreeBSD. I would like to keep that as a possible option, should things change around at RPI once again... -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Fri Aug 5 20:30:29 2005 Return-Path: X-Original-To: arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C3A8216A41F for ; Fri, 5 Aug 2005 20:30:29 +0000 (GMT) (envelope-from mark@grondar.org) Received: from storm.uk.FreeBSD.org (storm.uk.FreeBSD.org [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 070C643D46 for ; Fri, 5 Aug 2005 20:30:28 +0000 (GMT) (envelope-from mark@grondar.org) Received: from storm.uk.FreeBSD.org (uucp@localhost [127.0.0.1]) by storm.uk.FreeBSD.org (8.13.3/8.13.3) with ESMTP id j75KUQ2v054681; Fri, 5 Aug 2005 21:30:26 +0100 (BST) (envelope-from mark@grondar.org) Received: (from uucp@localhost) by storm.uk.FreeBSD.org (8.13.3/8.12.11/Submit) with UUCP id j75KUPFs054680; Fri, 5 Aug 2005 21:30:25 +0100 (BST) (envelope-from mark@grondar.org) Received: from grunt.grondar.org (localhost [127.0.0.1]) by grunt.grondar.org (8.13.4/8.13.4) with ESMTP id j75KPWxw039554; Fri, 5 Aug 2005 21:25:33 +0100 (BST) (envelope-from mark@grunt.grondar.org) Message-Id: <200508052025.j75KPWxw039554@grunt.grondar.org> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.0.4 To: Poul-Henning Kamp In-Reply-To: Message from Poul-Henning Kamp of "Fri, 05 Aug 2005 20:48:27 +0200." <21744.1123267707@phk.freebsd.dk> From: Mark Murray Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Aug 2005 21:25:32 +0100 Sender: mark@grondar.org Cc: arch@FreeBSD.ORG Subject: Re: putting HESIOD, Appletalk and IPX on notice X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2005 20:30:29 -0000 Poul-Henning Kamp writes: > >I think it is time we deorbit HESIOD in toto. OK - please give it _plenty_ of time. >At the same time, making Appletalk and IPX "opt in" facilities by >putting them under > YES_IPX >and > YES_APPLETALK >boolean build options seems a sensible move. Cool. I think the standard is "WANT_FOO", but that is a detail. It may be an idea to make these default to "off" in releases, but keep them in HEAD until they become too painful to care about. That would probably handle the CYB factor the best. M -- Mark R V Murray What is the most interesting question you have asked? What, if any, was the answer? From owner-freebsd-arch@FreeBSD.ORG Fri Aug 5 20:39:04 2005 Return-Path: X-Original-To: arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A824A16A421; Fri, 5 Aug 2005 20:39:04 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F30A43D48; Fri, 5 Aug 2005 20:39:04 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j75Kd3vf007159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Aug 2005 16:39:03 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j75Kd26P028581; Fri, 5 Aug 2005 16:39:03 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 2A18751358; Fri, 5 Aug 2005 16:39:02 -0400 (EDT) Date: Fri, 5 Aug 2005 16:39:02 -0400 From: Kris Kennaway To: Mark Murray Message-ID: <20050805203901.GA88453@xor.obsecurity.org> References: <21744.1123267707@phk.freebsd.dk> <200508052025.j75KPWxw039554@grunt.grondar.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: <200508052025.j75KPWxw039554@grunt.grondar.org> User-Agent: Mutt/1.4.2.1i Cc: Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: putting HESIOD, Appletalk and IPX on notice X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2005 20:39:04 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 05, 2005 at 09:25:32PM +0100, Mark Murray wrote: > Poul-Henning Kamp writes: > > > >I think it is time we deorbit HESIOD in toto. >=20 > OK - please give it _plenty_ of time. >=20 > >At the same time, making Appletalk and IPX "opt in" facilities by > >putting them under > > YES_IPX > >and > > YES_APPLETALK > >boolean build options seems a sensible move. >=20 > Cool. I think the standard is "WANT_FOO", but that is a detail. It=20 > may be an idea to make these default to "off" in releases, but keep > them in HEAD until they become too painful to care about. That=20 > would probably handle the CYB factor the best. Ports uses WITH_*/WITHOUT_* for user control knobs, and WANT_* is for internal port use only. Kris --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC885lWry0BWjoQKURAk7nAKCrHSnalXMGYGElUUs0Qk7noRcmHACgjhaV TqydAVSTHNZ+41y3gvf85IU= =twHp -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- From owner-freebsd-arch@FreeBSD.ORG Fri Aug 5 20:49:50 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A093116A41F for ; Fri, 5 Aug 2005 20:49:50 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A33C43D48 for ; Fri, 5 Aug 2005 20:49:50 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 8DA6A46B1A; Fri, 5 Aug 2005 16:49:49 -0400 (EDT) Date: Fri, 5 Aug 2005 21:52:31 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <21744.1123267707@phk.freebsd.dk> Message-ID: <20050805214650.H46767@fledge.watson.org> References: <21744.1123267707@phk.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: putting HESIOD, Appletalk and IPX on notice X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2005 20:49:50 -0000 On Fri, 5 Aug 2005, Poul-Henning Kamp wrote: > I think it is time we deorbit HESIOD in toto. > > At the same time, making Appletalk and IPX "opt in" facilities by > putting them under > YES_IPX > and > YES_APPLETALK > boolean build options seems a sensible move. > > Comments ? > > The first RELENG_7 release would happen in 2006 or 2007, there is no way > they will need any of those three protocols. Right now IPX and netatalk are already opt-in for the kernel, as the options are already non-default. I'm not sure we gain anything by doing that in user space, other than making it harder to turn them on (since presumably we're not talking more than a few hundred k in support code). I've found NETIPX and NETATALK both quite useful during the netperf work, as they help keep the protocol and socket type abstractions in the stack real, as well as explain why things are the way they are. My leaning would be to leave them as-is until early 2006, then take an executive decision then. Since there's not much point in talking solely about the user space parts, I think the decision should be about each protocol as a whole (kernel and userspace). At last today, I know that NETIPX is fairly widely used, because we received lots of bug reports when 5.3 shipped with it broken (as a result of a compiler change, it turns out). As a result, we now have a basic set of IPX and AppleTalk regression tests. I have no opinion on HESIOD, other than that I've always through it somewhat fun -- does MIT still deploy it? If not, then they may have been the last major site to do so. Probably, it would be useful to stuff HESIOD in ports since we now support NSS. I'd like to see us import LDAP support into the base system at some point so that we can support cAtive Directory integration better. Robert N M Watson From owner-freebsd-arch@FreeBSD.ORG Fri Aug 5 20:50:49 2005 Return-Path: X-Original-To: arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C3B9816A41F; Fri, 5 Aug 2005 20:50:49 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B9FA43D49; Fri, 5 Aug 2005 20:50:49 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id B092DBC6B; Fri, 5 Aug 2005 20:50:47 +0000 (UTC) To: Kris Kennaway From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 05 Aug 2005 16:39:02 EDT." <20050805203901.GA88453@xor.obsecurity.org> Date: Fri, 05 Aug 2005 22:50:47 +0200 Message-ID: <22301.1123275047@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: arch@FreeBSD.ORG, Mark Murray Subject: Re: putting HESIOD, Appletalk and IPX on notice X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2005 20:50:49 -0000 In message <20050805203901.GA88453@xor.obsecurity.org>, Kris Kennaway writes: >> Cool. I think the standard is "WANT_FOO", but that is a detail. It >> may be an idea to make these default to "off" in releases, but keep >> them in HEAD until they become too painful to care about. That >> would probably handle the CYB factor the best. > >Ports uses WITH_*/WITHOUT_* for user control knobs, and WANT_* is for >internal port use only. I can see a benefit from being orthogonal to ports usage in this, so I think the YES_FOO is actually the right thing. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sat Aug 6 07:28:10 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C992F16A41F for ; Sat, 6 Aug 2005 07:28:10 +0000 (GMT) (envelope-from julian@elischer.org) Received: from delight.idiom.com (delight.idiom.com [216.240.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 802ED43D49 for ; Sat, 6 Aug 2005 07:28:10 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id 48EC01FF6C8; Sat, 6 Aug 2005 00:28:10 -0700 (PDT) Received: from [192.168.2.3] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id j767S9ia094728; Sat, 6 Aug 2005 00:28:10 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <42F46681.10708@elischer.org> Date: Sat, 06 Aug 2005 00:28:01 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050424 X-Accept-Language: en, hu MIME-Version: 1.0 To: Poul-Henning Kamp References: <21744.1123267707@phk.freebsd.dk> In-Reply-To: <21744.1123267707@phk.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: putting HESIOD, Appletalk and IPX on notice X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2005 07:28:10 -0000 Poul-Henning Kamp wrote: > I think it is time we deorbit HESIOD in toto. > > At the same time, making Appletalk and IPX "opt in" facilities by > putting them under > YES_IPX > and > YES_APPLETALK how does this differ from options NETATALK and options NETIPX? Or do you mean for the complete build, i.e netstat etc. as well? My comment on both is that they do live as good working examples of other "foreign" network stacks.I also know that there are quite a few old MACS sitting around doing various pronter management functions etc. I don't know whether they will be gone by 2007 though. > boolean build options seems a sensible move. > > Comments ? > > The first RELENG_7 release would happen in 2006 or 2007, there is no way > they will need any of those three protocols. > From owner-freebsd-arch@FreeBSD.ORG Sat Aug 6 07:30:22 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35CFC16A41F for ; Sat, 6 Aug 2005 07:30:22 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id C985743D48 for ; Sat, 6 Aug 2005 07:30:21 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id A7A33BC66; Sat, 6 Aug 2005 07:30:17 +0000 (UTC) To: Julian Elischer From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 06 Aug 2005 00:28:01 PDT." <42F46681.10708@elischer.org> Date: Sat, 06 Aug 2005 09:30:17 +0200 Message-ID: <24777.1123313417@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: arch@freebsd.org Subject: Re: putting HESIOD, Appletalk and IPX on notice X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2005 07:30:22 -0000 In message <42F46681.10708@elischer.org>, Julian Elischer writes: >Poul-Henning Kamp wrote: >> I think it is time we deorbit HESIOD in toto. >> >> At the same time, making Appletalk and IPX "opt in" facilities by >> putting them under >> YES_IPX >> and >> YES_APPLETALK > > >how does this differ from >options NETATALK >and >options NETIPX? > >Or do you mean for the complete build, i.e netstat etc. as well? Yes, the complete build. >My comment on both is that they do live as good working examples of other >"foreign" network stacks.I also know that there are quite a few old MACS >sitting around doing various pronter management functions etc. I know they are, that's why I don't advocating sending them to the attic yet. But we have to look at how much idle code we keep around, and in particular we need to be sensitive to code we never look at which might contain security issues etc. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sat Aug 6 09:04:14 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3729A16A41F for ; Sat, 6 Aug 2005 09:04:14 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd2mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1D1A43D45 for ; Sat, 6 Aug 2005 09:04:13 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd3mr1so.prod.shaw.ca (pd3mr1so-qfe3.prod.shaw.ca [10.0.141.177]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IKS00DLZMBY2A40@l-daemon> for freebsd-arch@freebsd.org; Sat, 06 Aug 2005 02:59:58 -0600 (MDT) Received: from pn2ml2so.prod.shaw.ca ([10.0.121.146]) by pd3mr1so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IKS008XHMBYZNH0@pd3mr1so.prod.shaw.ca> for freebsd-arch@freebsd.org; Sat, 06 Aug 2005 02:59:58 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IKS00K6NMBXLG@l-daemon> for freebsd-arch@freebsd.org; Sat, 06 Aug 2005 02:59:58 -0600 (MDT) Date: Sat, 06 Aug 2005 01:59:57 -0700 From: Colin Percival To: "freebsd-arch@freebsd.org" Message-id: <42F47C0D.2020704@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050724) Subject: /usr/portsnap vs. /var/db/portsnap X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2005 09:04:14 -0000 I'm going to be bringing portsnap into the base system very soon, and I have a slight problem: I don't know where I should put the default working directory. Portsnap keeps a compressed snapshot of the ports tree, requiring roughly 50MB and 13000 inodes. The "natural" place for this to go would be in /var/db/, but I suspect that this would cause problems for many users, particularly when it comes to the number of inodes. Is this a reasonable excuse for violating hier(7) and putting the compressed snapshot into /usr/portsnap? For reference, the port keeps the snapshot in /usr/local/portsnap. Colin Percival From owner-freebsd-arch@FreeBSD.ORG Sat Aug 6 09:22:35 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAC4716A41F; Sat, 6 Aug 2005 09:22:35 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24C2E43D48; Sat, 6 Aug 2005 09:22:35 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 8917A11B07; Sat, 6 Aug 2005 11:22:33 +0200 (CEST) Date: Sat, 6 Aug 2005 11:22:33 +0200 From: "Simon L. Nielsen" To: Colin Percival Message-ID: <20050806092232.GA850@zaphod.nitro.dk> References: <42F47C0D.2020704@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline In-Reply-To: <42F47C0D.2020704@freebsd.org> User-Agent: Mutt/1.5.9i Cc: "freebsd-arch@freebsd.org" Subject: Re: /usr/portsnap vs. /var/db/portsnap X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2005 09:22:36 -0000 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2005.08.06 01:59:57 -0700, Colin Percival wrote: > Portsnap keeps a compressed snapshot of the ports tree, requiring > roughly 50MB and 13000 inodes. The "natural" place for this to go > would be in /var/db/, but I suspect that this would cause problems > for many users, particularly when it comes to the number of inodes. >=20 > Is this a reasonable excuse for violating hier(7) and putting the > compressed snapshot into /usr/portsnap? For reference, the port keeps > the snapshot in /usr/local/portsnap. Wouldn't it make sense to put in on /var, and if people do not have enough space there, they can just symlink the portsnap directory to a location that has enough space? --=20 Simon L. Nielsen --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC9IFYh9pcDSc1mlERAlxeAKCYtZBfomQibSPqvsQvqn3ajZpAhQCfd1tJ sDcRwodITmmz/DQSCsujY60= =Rz/x -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx-- From owner-freebsd-arch@FreeBSD.ORG Sat Aug 6 09:22:55 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71D6E16A41F; Sat, 6 Aug 2005 09:22:55 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE5A943D48; Sat, 6 Aug 2005 09:22:54 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.13.3/8.13.3/NinthNine) with SMTP id j769Mr6r069800; Sat, 6 Aug 2005 18:22:53 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sat, 6 Aug 2005 18:22:53 +0900 (JST) Message-Id: <200508060922.j769Mr6r069800@sakura.ninth-nine.com> From: Norikatsu Shigemura To: Colin Percival In-Reply-To: <42F47C0D.2020704@freebsd.org> References: <42F47C0D.2020704@freebsd.org> X-Mailer: Sylpheed version 2.0.0 (GTK+ 2.6.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sakura.ninth-nine.com [219.127.74.121]); Sat, 06 Aug 2005 18:22:53 +0900 (JST) Cc: freebsd-arch@FreeBSD.org Subject: Re: /usr/portsnap vs. /var/db/portsnap X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2005 09:22:55 -0000 On Sat, 06 Aug 2005 01:59:57 -0700 Colin Percival wrote: > Portsnap keeps a compressed snapshot of the ports tree, requiring > roughly 50MB and 13000 inodes. The "natural" place for this to go > would be in /var/db/, but I suspect that this would cause problems > for many users, particularly when it comes to the number of inodes. > Is this a reasonable excuse for violating hier(7) and putting the > compressed snapshot into /usr/portsnap? For reference, the port keeps > the snapshot in /usr/local/portsnap. Cvsup (/usr/share/examples/cvsup/ports-supfile) put /var/db/sup. So portsnap should put on /var/db. At least, we should be able to 'mount -ro /usr'. /var/db/portsnap causes a problem to users, ln -s /usr/portsnap /var/db/portnap. From owner-freebsd-arch@FreeBSD.ORG Sat Aug 6 10:05:47 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E61C316A41F; Sat, 6 Aug 2005 10:05:47 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd3mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89BB643D49; Sat, 6 Aug 2005 10:05:47 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd5mr3so.prod.shaw.ca (pd5mr3so-qfe3.prod.shaw.ca [10.0.141.144]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IKS00FDSP26I430@l-daemon>; Sat, 06 Aug 2005 03:58:54 -0600 (MDT) Received: from pn2ml2so.prod.shaw.ca ([10.0.121.146]) by pd5mr3so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IKS0032ZP266OB0@pd5mr3so.prod.shaw.ca>; Sat, 06 Aug 2005 03:58:54 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IKS00D03P25DG@l-daemon>; Sat, 06 Aug 2005 03:58:54 -0600 (MDT) Date: Sat, 06 Aug 2005 02:58:52 -0700 From: Colin Percival In-reply-to: <20050806092232.GA850@zaphod.nitro.dk> To: "Simon L. Nielsen" Message-id: <42F489DC.1080400@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en References: <42F47C0D.2020704@freebsd.org> <20050806092232.GA850@zaphod.nitro.dk> User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050724) Cc: "freebsd-arch@freebsd.org" Subject: Re: /usr/portsnap vs. /var/db/portsnap X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2005 10:05:48 -0000 Simon L. Nielsen wrote: > On 2005.08.06 01:59:57 -0700, Colin Percival wrote: >>Is this a reasonable excuse for violating hier(7) and putting the >>compressed snapshot into /usr/portsnap? For reference, the port keeps >>the snapshot in /usr/local/portsnap. > > Wouldn't it make sense to put in on /var, and if people do not have > enough space there, they can just symlink the portsnap directory to a > location that has enough space? Probably... I'm just worried about inexperienced FreeBSD users who would see an error message about /var being full and not know what to do about it. Colin Percival From owner-freebsd-arch@FreeBSD.ORG Sat Aug 6 11:21:21 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD9F916A41F; Sat, 6 Aug 2005 11:21:21 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4475243D46; Sat, 6 Aug 2005 11:21:21 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail13.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j76BLII4032109 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 6 Aug 2005 21:21:19 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j76BLISR007789; Sat, 6 Aug 2005 21:21:18 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j76BLIMh007788; Sat, 6 Aug 2005 21:21:18 +1000 (EST) (envelope-from pjeremy) Date: Sat, 6 Aug 2005 21:21:18 +1000 From: Peter Jeremy To: Colin Percival Message-ID: <20050806112118.GA7708@cirb503493.alcatel.com.au> References: <42F47C0D.2020704@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42F47C0D.2020704@freebsd.org> User-Agent: Mutt/1.4.2i Cc: "freebsd-arch@freebsd.org" Subject: Re: /usr/portsnap vs. /var/db/portsnap X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2005 11:21:22 -0000 On Sat, 2005-Aug-06 01:59:57 -0700, Colin Percival wrote: >I'm going to be bringing portsnap into the base system very soon, and >roughly 50MB and 13000 inodes. The "natural" place for this to go >would be in /var/db/, but I suspect that this would cause problems >for many users, particularly when it comes to the number of inodes. The number of inodes does seem rather high (I gather it's one per port). Have you considered using an alternative mechanism to store the data? ar(1), dbm(3) and zip(1) would all seem possible options (though zip isn't in the base system). The downside is that updating would be far more expensive in disk space. >Is this a reasonable excuse for violating hier(7) and putting the >compressed snapshot into /usr/portsnap? For reference, the port keeps >the snapshot in /usr/local/portsnap. I think it would be nicer to have it in /var. I suspect that that many inodes may present problems for some people whereever you put it. Maybe you need to make the location an option (either compile time or in a configuration file) -- Peter Jeremy From owner-freebsd-arch@FreeBSD.ORG Sat Aug 6 11:51:01 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6360816A41F for ; Sat, 6 Aug 2005 11:51:01 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd2mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE21843D5E for ; Sat, 6 Aug 2005 11:51:00 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd4mr6so.prod.shaw.ca (pd4mr6so-qfe3.prod.shaw.ca [10.0.141.69]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IKS00CMTTM49390@l-daemon> for freebsd-arch@freebsd.org; Sat, 06 Aug 2005 05:37:16 -0600 (MDT) Received: from pn2ml2so.prod.shaw.ca ([10.0.121.146]) by pd4mr6so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IKS00EZUTM4R060@pd4mr6so.prod.shaw.ca> for freebsd-arch@freebsd.org; Sat, 06 Aug 2005 05:37:16 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IKS00K06TM3LT@l-daemon> for freebsd-arch@freebsd.org; Sat, 06 Aug 2005 05:37:16 -0600 (MDT) Date: Sat, 06 Aug 2005 04:37:15 -0700 From: Colin Percival In-reply-to: <20050806112118.GA7708@cirb503493.alcatel.com.au> To: Peter Jeremy Message-id: <42F4A0EB.1080009@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en References: <42F47C0D.2020704@freebsd.org> <20050806112118.GA7708@cirb503493.alcatel.com.au> User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050724) Cc: "freebsd-arch@freebsd.org" Subject: Re: /usr/portsnap vs. /var/db/portsnap X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2005 11:51:01 -0000 Peter Jeremy wrote: > On Sat, 2005-Aug-06 01:59:57 -0700, Colin Percival wrote: >>I'm going to be bringing portsnap into the base system very soon, and >>roughly 50MB and 13000 inodes. > > The number of inodes does seem rather high (I gather it's one per > port). Have you considered using an alternative mechanism to store > the data? ar(1), dbm(3) and zip(1) would all seem possible options > (though zip isn't in the base system). The downside is that updating > would be far more expensive in disk space. I considered it, but for performance reasons it is much better to keep each port as a separate file. > I think it would be nicer to have it in /var. I suspect that that > many inodes may present problems for some people whereever you put it. I don't think 13000 inodes will be a big problem on /usr for most people. The rather small drive on my laptop has two million inodes allocated for /usr. > Maybe you need to make the location an option (either compile time or > in a configuration file) It is configurable. Ok, I'll make /var/db/portsnap the default and tell people to change that in /etc/portsnap.conf if they want. Colin Percival From owner-freebsd-arch@FreeBSD.ORG Sat Aug 6 11:58:48 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3379E16A41F for ; Sat, 6 Aug 2005 11:58:48 +0000 (GMT) (envelope-from pawel.worach@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id BACE243D45 for ; Sat, 6 Aug 2005 11:58:47 +0000 (GMT) (envelope-from pawel.worach@gmail.com) Received: by wproxy.gmail.com with SMTP id i11so522606wra for ; Sat, 06 Aug 2005 04:58:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WT5pkC+rYFl2H7IuOb5hfpA82Cx3JuB8t+xAzgpNq3Ximwh63ExEoX768yyTbF2ASR5yeVfsk3Mt0dxzwWjxQLAJxoPeJ6u1OxmNDJMjmNTKCviLg2YORRxKlm4kPvb6gnbQhQXCl6/KL9cQOUd0OiRXZ3VdhJOPXtG3duonPj8= Received: by 10.54.43.79 with SMTP id q79mr3374462wrq; Sat, 06 Aug 2005 04:58:47 -0700 (PDT) Received: by 10.54.118.16 with HTTP; Sat, 6 Aug 2005 04:58:47 -0700 (PDT) Message-ID: Date: Sat, 6 Aug 2005 13:58:47 +0200 From: Pawel Worach To: Craig Rodrigues In-Reply-To: <20050803200143.GA70735@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050803200143.GA70735@crodrigues.org> Cc: freebsd-arch@freebsd.org Subject: Re: [RFC] Kernel patches for compilation with gcc 4.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pawel Worach List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2005 11:58:48 -0000 On 8/3/05, Craig Rodrigues wrote: > I had to apply these patches: > http://people.freebsd.org/~rodrigc/fbsd.makefiles.diff.txt >=20 > to the kernel makefile rules because "-I-" is removed from gcc 4.0, > and "-fformat-extensions" is a FreeBSD extension to GCC which is not > in the ports version of the compiler. >=20 I have played with merging the system compiler features to the gcc 4.0.x br= anch. The result is available here: http://62.119.221.30/gcc4/ Currently there is a defect in our system compiler, you can use the format-extenstions without specifying the -fformat-extensions argument since flag_format_extensions is never checked, I fixed that and instead it yields a strange warning so I don't know if it's entirely correct. We also had some other variables (one of them which duplicated the purpose of flag_format_extensions) which where never used, likely left-over bits from gcc 2.x days. I have only tested it on i386 and the box booted the resulting kernel just fine to single-user, the compiler speed is a bit slower but the difference was smaller than I expected. Thanks for the kernel patches Craig! --=20 Pawel From owner-freebsd-arch@FreeBSD.ORG Sat Aug 6 14:38:16 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADF7016A426; Sat, 6 Aug 2005 14:38:16 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from mortis.over-yonder.net (adsl-152-70-24.jan.bellsouth.net [70.152.70.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 367AC43D62; Sat, 6 Aug 2005 14:38:15 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: by mortis.over-yonder.net (Postfix, from userid 100) id A9E3720F60; Sat, 6 Aug 2005 09:38:12 -0500 (CDT) Date: Sat, 6 Aug 2005 09:38:12 -0500 From: "Matthew D. Fuller" To: Peter Jeremy Message-ID: <20050806143812.GA76296@over-yonder.net> References: <42F47C0D.2020704@freebsd.org> <20050806112118.GA7708@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050806112118.GA7708@cirb503493.alcatel.com.au> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.9i-fullermd.2 Cc: Colin Percival , "freebsd-arch@freebsd.org" Subject: Re: /usr/portsnap vs. /var/db/portsnap X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2005 14:38:16 -0000 On Sat, Aug 06, 2005 at 09:21:18PM +1000 I heard the voice of Peter Jeremy, and lo! it spake thus: > > I think it would be nicer to have it in /var. I suspect that that > many inodes may present problems for some people whereever you put > it. I doubt it presents much problem as regards the 'running out' issue anyway. Things like fsck time, maybe. But I've got a rather oldish and rather smallish /var, and: Filesystem Size Used Avail Capacity iused ifree %iused Mounted on /dev/da1s1f 992M 266M 647M 29% 3802 250148 1% /var 13k inodes wouldn't faze it. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-arch@FreeBSD.ORG Sat Aug 6 17:36:41 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F05D16A41F for ; Sat, 6 Aug 2005 17:36:41 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd3mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6DCB43D60 for ; Sat, 6 Aug 2005 17:36:40 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd2mr7so.prod.shaw.ca (pd2mr7so-qfe3.prod.shaw.ca [10.0.141.10]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IKT002DWA2VM110@l-daemon> for freebsd-arch@freebsd.org; Sat, 06 Aug 2005 11:32:55 -0600 (MDT) Received: from pn2ml8so.prod.shaw.ca ([10.0.121.152]) by pd2mr7so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IKT00FIJA2VU550@pd2mr7so.prod.shaw.ca> for freebsd-arch@freebsd.org; Sat, 06 Aug 2005 11:32:55 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IKT00C6LA2V5E@l-daemon> for freebsd-arch@freebsd.org; Sat, 06 Aug 2005 11:32:55 -0600 (MDT) Date: Sat, 06 Aug 2005 10:32:54 -0700 From: Colin Percival In-reply-to: <20050806143812.GA76296@over-yonder.net> To: "Matthew D. Fuller" Message-id: <42F4F446.90304@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en References: <42F47C0D.2020704@freebsd.org> <20050806112118.GA7708@cirb503493.alcatel.com.au> <20050806143812.GA76296@over-yonder.net> User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050724) Cc: Peter Jeremy , "freebsd-arch@freebsd.org" Subject: Re: /usr/portsnap vs. /var/db/portsnap X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2005 17:36:41 -0000 Matthew D. Fuller wrote: > I doubt it presents much problem as regards the 'running out' issue > anyway. Things like fsck time, maybe. But I've got a rather oldish > and rather smallish /var, and: > > Filesystem Size Used Avail Capacity iused ifree %iused Mounted on > /dev/da1s1f 992M 266M 647M 29% 3802 250148 1% /var Your "rather oldish and rather smallish" /var is four times the default size used in sysinstall (256MB is used for /, /tmp, and /var if you have a large enough drive). This default results in having ~32000 inodes. I wonder if it's time to increase the default size of /var again. Colin Percival From owner-freebsd-arch@FreeBSD.ORG Sat Aug 6 17:55:08 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2B1A16A424 for ; Sat, 6 Aug 2005 17:55:08 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: from mailserv1.neuroflux.com (ns2.neuroflux.com [204.228.228.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id D552743D49 for ; Sat, 6 Aug 2005 17:55:07 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 28865 invoked by uid 1003); 6 Aug 2005 17:55:49 -0000 Received: from ryans@gamersimpact.com by mailserv1.neuroflux.com by uid 89 with qmail-scanner-1.22 (clamscan: 0.65. spamassassin: 2.60. Clear:RC:1(63.229.214.54):. Processed in 1.345341 secs); 06 Aug 2005 17:55:49 -0000 Received: from unknown (HELO ?192.168.0.3?) (63.229.214.54) by mailserv1.neuroflux.com with SMTP; 6 Aug 2005 17:55:47 -0000 Message-ID: <42F4F979.7080705@gamersimpact.com> Date: Sat, 06 Aug 2005 12:55:05 -0500 From: Ryan Sommers User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Percival References: <42F47C0D.2020704@freebsd.org> <20050806112118.GA7708@cirb503493.alcatel.com.au> <20050806143812.GA76296@over-yonder.net> <42F4F446.90304@freebsd.org> In-Reply-To: <42F4F446.90304@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-arch@freebsd.org" Subject: Re: /usr/portsnap vs. /var/db/portsnap X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2005 17:55:08 -0000 Colin Percival wrote: > Your "rather oldish and rather smallish" /var is four times the default > size used in sysinstall (256MB is used for /, /tmp, and /var if you have > a large enough drive). This default results in having ~32000 inodes. > > I wonder if it's time to increase the default size of /var again. I would agree, even without portsnap. With things like MySQL using /var/db (if I remember) as the default it might be a way to avoid a few more mails to questions@ without impacting the normal user. Hard drives are pennies to the GB and always getting cheaper; I've been making 1-5gb /var's for awhile even on non-database servers just to have a little more wiggle room for logs. As a side note, I've always wished we had a selectable list of "auto" configure options, database server, web-server, minimalist, etc. -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-arch@FreeBSD.ORG Sat Aug 6 20:11:53 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16D1416A41F for ; Sat, 6 Aug 2005 20:11:53 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail1.fluidhosting.com (mail1.fluidhosting.com [204.14.90.61]) by mx1.FreeBSD.org (Postfix) with SMTP id 0DC8B43D49 for ; Sat, 6 Aug 2005 20:11:50 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 73630 invoked by uid 399); 6 Aug 2005 20:11:50 -0000 Received: from mail1.fluidhosting.com (66.150.201.101) by mail1.fluidhosting.com with SMTP; 6 Aug 2005 20:11:50 -0000 Received: (qmail 69052 invoked by uid 399); 6 Aug 2005 20:11:49 -0000 Received: from unknown (HELO ?192.168.1.101?) (dougb@dougbarton.net@69.175.228.47) by mail1.fluidhosting.com with SMTP; 6 Aug 2005 20:11:49 -0000 Message-ID: <42F51979.2020509@FreeBSD.org> Date: Sat, 06 Aug 2005 13:11:37 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Percival References: <42F47C0D.2020704@freebsd.org> In-Reply-To: <42F47C0D.2020704@freebsd.org> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-arch@freebsd.org" Subject: Re: /usr/portsnap vs. /var/db/portsnap X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2005 20:11:53 -0000 Colin Percival wrote: > I'm going to be bringing portsnap into the base system very soon Pardon my ignorance, but where can I find the discussion where this was agreed? I assume in the archives on -arch somewhere, with some input from portmgr? Thanks, Doug From owner-freebsd-arch@FreeBSD.ORG Sat Aug 6 22:13:38 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11EC116A41F; Sat, 6 Aug 2005 22:13:38 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5159143D46; Sat, 6 Aug 2005 22:13:37 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j76MDWPP016628; Sun, 7 Aug 2005 08:13:32 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j76MDSrU018738; Sun, 7 Aug 2005 08:13:29 +1000 Date: Sun, 7 Aug 2005 08:13:27 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Xin LI In-Reply-To: <20050802164120.GA16775@frontfree.net> Message-ID: <20050807050237.H3151@epsplex.bde.org> References: <20050801182518.GA85423@frontfree.net> <20050802013916.GA37135@dragon.NUXI.org> <20050802164120.GA16775@frontfree.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2005 22:13:38 -0000 On Wed, 3 Aug 2005, Xin LI wrote: > On Mon, Aug 01, 2005 at 06:39:16PM -0700, David O'Brien wrote: >> On Tue, Aug 02, 2005 at 02:25:18AM +0800, Xin LI wrote: >>> Here is a patchset that I have produced to make our libc aware of the >>> NetBSD assembly implementation of the string related operations. >> >> What performance benchmarks have these been thru? I would expect insignificant ones. alc already optimized most of the amd64 string functions that are worth optimizing. > In summary: index, rindex, memchr, strchr, strlen, strlen, strrchr are > faster than their C counterparts; ffs, strncmp are about the same, and > swab is worse. This is not surprising, since the faster ones mostly use better algorithms so their fastness has very little to do with them being written in asm, ffs.S has slightly worse code than the gcc builtin, strncmp.S doesn't do anything special, and swab.S does almost everything pessimally. > Note that these tests are done within loops that first copy a string to > a new place, then perform the operation, then free the string, to defeat > cache effects. I usually test like this since it is hard to do better, but this tests for precisely things that shouldn't happen in real applications. > BETTER CASES > > [delphij@warrior7] ~/test/index> /usr/bin/time ./index > 5.81 real 5.79 user 0.00 sys > ASSEMBLY > 1.84 real 1.82 user 0.00 sys > > [delphij@warrior7] ~/test/rindex> /usr/bin/time ./rindex > 6.25 real 6.24 user 0.00 sys > ASSEMBLY > 2.17 real 1.84 user 0.01 sys > > [delphij@warrior7] ~/test/memchr> /usr/bin/time ./memchr > 5.93 real 5.91 user 0.00 sys > ASSEMBLY > 1.91 real 1.84 user 0.00 sys > > [delphij@warrior7] ~/test/strchr> /usr/bin/time ./strchr > 5.93 real 5.91 user 0.00 sys > ASSEMBLY > 1.84 real 1.83 user 0.00 sys memchr.S, strchr.S (and thus index.S), strchchr.S (strchr timings below) (and thus rindex.S) all use the well known method of comparing with the magic byte sequences \x80\x80... and \x01\0x01... It's not surprising that this is several times faster since it accesses the data 4-8 bytes at a time (8 bytes for amd64), but IMO this optimization belongs only in C code (if anywhere) so that it optimizes all arches (if it is an optimization). glibc has it in C code. NetBSD also has it in the i386 string library but not in the generic string library. > [delphij@warrior7] ~/test/strlen> /usr/bin/time ./strlen > 7.13 real 7.12 user 0.00 sys > ASSEMBLY > 1.44 real 1.43 user 0.00 sys strlen.S uses the magic byte sequence method in the same way (NetBSD also does this in the i386 strlen.S...). The method works even better for strlen(), giving closer to an 8-fold speedup, since there is less overhead. Other benchmarks for strlen() show strange behaviour. (Note that neither the generic library version nor the MD i386/amd64 version of it is normally used, since the gcc builtin is normally used.) - the builtin is slightly faster than the MD i386 version, since they use the same algorithm (a scasb loop) and the builtin doesn't have function call overhead. - the simple generic C version is often faster than the "optimized" builtin! IIRC, alc noticed this for amd64 and didn't implement an amd64 strlen.S using the same simple algorithm as the i386 one because it would be a pessimization even if it were actually used. It seems to be pessimal on Athlon XP's too. For 10^8 strlen()s, with other CFLAGS -O2 -static: on an AXP2600 overclocked: %%% string length 0: algorithm -fbuiltin: 0.30 real 0.29 user 0.00 sys algorithm -fno-builtin: 0.33 real 0.32 user 0.00 sys algorithm -DMISTRLEN: 0.25 real 0.24 user 0.00 sys string length 1: algorithm -fbuiltin: 0.31 real 0.30 user 0.00 sys algorithm -fno-builtin: 0.34 real 0.33 user 0.00 sys algorithm -DMISTRLEN: 0.26 real 0.25 user 0.00 sys string length 10: algorithm -fbuiltin: 0.40 real 0.39 user 0.00 sys algorithm -fno-builtin: 0.43 real 0.42 user 0.00 sys algorithm -DMISTRLEN: 0.40 real 0.39 user 0.00 sys string length 100: algorithm -fbuiltin: 1.32 real 1.30 user 0.00 sys algorithm -fno-builtin: 1.35 real 1.33 user 0.00 sys algorithm -DMISTRLEN: 1.21 real 1.20 user 0.00 sys string length 1000: algorithm -fbuiltin: 10.46 real 10.42 user 0.00 sys algorithm -fno-builtin: 10.50 real 10.46 user 0.00 sys algorithm -DMISTRLEN: 9.35 real 9.31 user 0.00 sys %%% Note that the MI version is fastest for all string lengths. The C version was sometimes (in results with -O1 and/or not shown above) 30% slower than it usually is; this turned out to be due to the loop in strlen() not fitting in a cache line due to the start of the loop accidentally beginning near a cache line boundary. On an A64 3400: %%% string length 0: algorithm -fbuiltin: 0.34 real 0.32 user 0.00 sys algorithm -fno-builtin: 0.24 real 0.23 user 0.00 sys algorithm -fno-builtin zq.S: 0.27 real 0.26 user 0.00 sys string length 1: algorithm -fbuiltin: 0.35 real 0.33 user 0.00 sys algorithm -fno-builtin: 0.25 real 0.24 user 0.00 sys algorithm -fno-builtin zq.S: 0.29 real 0.28 user 0.00 sys string length 10: algorithm -fbuiltin: 0.44 real 0.42 user 0.00 sys algorithm -fno-builtin: 0.42 real 0.40 user 0.00 sys algorithm -fno-builtin zq.S: 0.30 real 0.29 user 0.00 sys string length 100: algorithm -fbuiltin: 1.34 real 1.32 user 0.00 sys algorithm -fno-builtin: 1.32 real 1.30 user 0.00 sys algorithm -fno-builtin zq.S: 0.55 real 0.54 user 0.00 sys string length 1000: algorithm -fbuiltin: 10.39 real 10.37 user 0.00 sys algorithm -fno-builtin: 10.37 real 10.34 user 0.00 sys algorithm -fno-builtin zq.S: 2.25 real 2.23 user 0.00 sys %%% zq.S is your proposed strlen.S. > > [delphij@warrior7] ~/test/strrchr> /usr/bin/time ./strrchr > 9.12 real 9.08 user 0.00 sys > ASSEMBLY > 4.71 real 4.69 user 0.00 sys > > WORSE/NO EFFECTS > > [delphij@warrior7] ~/test/ffs> /usr/bin/time ./ffs > 0.33 real 0.33 user 0.00 sys > ASSEMBLY > 0.33 real 0.33 user 0.00 sys The MI library version is poor for ffs, but the builtin is good. It is easy to improve the MI version, at least in benchmarks, using a lookup table, but efficiency of ffs() is unimportant in most applications so no one has done it. From an old benchmark of various methods on an A64: %%% UNIFORM/BUILTIN_FFS: 0.27 real 0.26 user 0.00 sys UNIFORM/CPUFUNC_FFS: 0.27 real 0.26 user 0.00 sys UNIFORM/LIBMET0_FFS: 0.70 real 0.70 user 0.00 sys UNIFORM/LIBMETH_FFS: 0.72 real 0.72 user 0.00 sys UNIFORM/LUTMETH_FFS: 0.25 real 0.24 user 0.00 sys UNIFORM/CPUFUNC_FLS: 0.33 real 0.33 user 0.00 sys UNIFORM/ILOGMET_FLS: 0.18 real 0.18 user 0.00 sys UNIFORM/ILOGBME_FLS: 0.37 real 0.36 user 0.00 sys UNIFORM/ILOGBM0_FLS: 0.39 real 0.39 user 0.00 sys UNIFORM/LIBMET0_FLS: 1.67 real 1.67 user 0.00 sys UNIFORM/LIBMETH_FLS: 1.71 real 1.71 user 0.00 sys RANDBIT/BUILTIN_FFS: 0.27 real 0.26 user 0.00 sys RANDBIT/CPUFUNC_FFS: 0.27 real 0.26 user 0.00 sys RANDBIT/LIBMET0_FFS: 1.43 real 1.43 user 0.00 sys RANDBIT/LIBMETH_FFS: 1.44 real 1.43 user 0.00 sys RANDBIT/LUTMETH_FFS: 0.25 real 0.24 user 0.00 sys RANDBIT/CPUFUNC_FLS: 0.33 real 0.33 user 0.00 sys RANDBIT/ILOGMET_FLS: 0.17 real 0.17 user 0.00 sys RANDBIT/ILOGBME_FLS: 0.41 real 0.41 user 0.00 sys RANDBIT/ILOGBM0_FLS: 0.39 real 0.39 user 0.00 sys RANDBIT/LIBMET0_FLS: 1.16 real 1.16 user 0.00 sys RANDBIT/LIBMETH_FLS: 1.16 real 1.16 user 0.00 sys ALLZERO/BUILTIN_FFS: 0.27 real 0.26 user 0.00 sys ALLZERO/CPUFUNC_FFS: 0.27 real 0.26 user 0.00 sys ALLZERO/LIBMET0_FFS: 0.53 real 0.53 user 0.00 sys ALLZERO/LIBMETH_FFS: 0.55 real 0.55 user 0.00 sys ALLZERO/LUTMETH_FFS: 0.12 real 0.12 user 0.00 sys ALLZERO/CPUFUNC_FLS: 0.10 real 0.10 user 0.00 sys ALLZERO/ILOGMET_FLS: 0.12 real 0.12 user 0.00 sys ALLZERO/ILOGBME_FLS: 0.12 real 0.12 user 0.00 sys ALLZERO/ILOGBM0_FLS: 0.10 real 0.10 user 0.00 sys ALLZERO/LIBMET0_FLS: 0.24 real 0.24 user 0.00 sys ALLZERO/LIBMETH_FLS: 0.29 real 0.28 user 0.00 sys ALLONE_/BUILTIN_FFS: 0.27 real 0.26 user 0.00 sys ALLONE_/CPUFUNC_FFS: 0.27 real 0.26 user 0.00 sys ALLONE_/LIBMET0_FFS: 0.58 real 0.57 user 0.00 sys ALLONE_/LIBMETH_FFS: 0.60 real 0.59 user 0.00 sys ALLONE_/LUTMETH_FFS: 0.25 real 0.24 user 0.00 sys ALLONE_/CPUFUNC_FLS: 0.37 real 0.37 user 0.00 sys ALLONE_/ILOGMET_FLS: 0.16 real 0.16 user 0.00 sys ALLONE_/ILOGBME_FLS: 0.37 real 0.37 user 0.00 sys ALLONE_/ILOGBM0_FLS: 0.39 real 0.39 user 0.00 sys ALLONE_/LIBMET0_FLS: 0.25 real 0.24 user 0.00 sys ALLONE_/LIBMETH_FLS: 0.29 real 0.28 user 0.00 sys ALLLAST/BUILTIN_FFS: 0.27 real 0.26 user 0.00 sys ALLLAST/CPUFUNC_FFS: 0.27 real 0.26 user 0.00 sys ALLLAST/LIBMET0_FFS: 2.37 real 2.36 user 0.00 sys ALLLAST/LIBMETH_FFS: 2.39 real 2.38 user 0.00 sys ALLLAST/LUTMETH_FFS: 0.25 real 0.24 user 0.00 sys ALLLAST/CPUFUNC_FLS: 0.37 real 0.37 user 0.00 sys ALLLAST/ILOGMET_FLS: 0.12 real 0.12 user 0.00 sys ALLLAST/ILOGBME_FLS: 0.37 real 0.37 user 0.00 sys ALLLAST/ILOGBM0_FLS: 0.39 real 0.39 user 0.00 sys ALLLAST/LIBMET0_FLS: 1.77 real 1.76 user 0.00 sys ALLLAST/LIBMETH_FLS: 1.81 real 1.81 user 0.00 sys %%% Here various distributions of the bits are tested, with various algorithms: BUILTIN_FFS: whatever gcc gives CPUFUNC_FFS: as in (this uses the builtin for amd64) LIBMET0_FFS: LIBMETH_FFS compiled with benchmark's CFLAGS LIBMETH_FFS: MI library method LUTMETH_FFS: a lookup table method, orignally by cperciva CPUFUNC_FLS: whatever gcc gives ILOGMET_FLS: convert to floating point and extract the exponent directly ILOGBME_FLS: convert to floating point and use ilogb(3) to extract... ILOGBM0_FLS: ILOGBM0_FLS compiled with benchmark's CFLAGS LIBMET0_FLS: MI library method compiled with benchmark's CFLAGS LIBMETH_FLS: MI library method > [delphij@warrior7] ~/test/strncmp> /usr/bin/time ./strncmp > 3.90 real 3.88 user 0.00 sys > 3.88 real 3.87 user 0.00 sys > ASSEMBLY > 3.88 real 3.87 user 0.00 sys > > [delphij@warrior7] ~/test/swab> /usr/bin/time ./swab > 6.59 real 6.53 user 0.01 sys > ASSEMBLY > 8.06 real 8.05 user 0.00 sys > Some comments on the patch. % Index: ffs.S % =================================================================== % RCS file: ffs.S % diff -N ffs.S % --- /dev/null 1 Jan 1970 00:00:00 -0000 % +++ ffs.S 1 Aug 2005 17:54:04 -0000 % @@ -0,0 +1,22 @@ % +/* % + * Written by J.T. Conklin . % + * Public domain. % + * Adapted for NetBSD/x86_64 by Frank van der Linden % + */ % + % +#include % +__FBSDID("$FreeBSD$"); % + % +#if 0 % + RCSID("$NetBSD: ffs.S,v 1.2 2003/07/26 19:24:38 salo Exp $") % +#endif % + % +ENTRY(ffs) % + bsfl %edi,%eax % + jz L1 /* ZF is set if all bits are 0 */ % + incl %eax /* bits numbered from 1, not 0 */ % + ret % + % + .align 4 % +L1: xorl %eax,%eax /* clear result */ % + ret The amd64 builtin uses cmove to avoid the branch. This is always better, but is only a small optimization (see above benchmark). The i386 ffs() does the test and branch before the bsfl so as to avoid the bsfl if the arg is 0. This sigificantly optimimizes the case of a zero arg at no cost for nonzero args. The gcc builtin ffs() has evolved in many stages: - very old versions depended on undefined behaviour. The i386 kernel ffs() was written to avoid this bug and it was easy to optimize it while doing this. - not old versions generated essentially the above code. - not so old versions (3.3.3) generate "sete; negl; orl" to avoid the branch. This is a less efficient variant of the cmove. % Index: memchr.S % =================================================================== % RCS file: memchr.S % diff -N memchr.S % --- /dev/null 1 Jan 1970 00:00:00 -0000 % +++ memchr.S 1 Aug 2005 18:09:44 -0000 % @@ -0,0 +1,112 @@ This is good code (algorithm and style). I don't mind using this micro-optimization if someone else writes and maintains it :-). % ... % +.Lzero: % + xorq %rax,%rax Some of the other functions only return %eax, which is sufficient for an int but is a different style. % Index: strchr.S % =================================================================== % RCS file: strchr.S % diff -N strchr.S % --- /dev/null 1 Jan 1970 00:00:00 -0000 % +++ strchr.S 1 Aug 2005 18:11:51 -0000 % @@ -0,0 +1,137 @@ Similarly to memchr.S.... % ... % + subq $7,%rdi % + jmp .Ldone % +1: testb %dl,%dl /* 2nd byte == 0? */ ... but not so good style near the end of it: - nameless labels are fairly easy to write but hard to read - no blank line before separate blocks of code - labels on the same line as statements % Index: strlen.S % =================================================================== % RCS file: strlen.S % diff -N strlen.S % --- /dev/null 1 Jan 1970 00:00:00 -0000 % +++ strlen.S 1 Aug 2005 18:12:48 -0000 % @@ -0,0 +1,157 @@ Not as good style as memchr.S. % + /* % + * There are many well known branch-free sequences which are used % + * for determining whether a zero-byte is contained within a word. % + * These sequences are generally much more efficent than loading % + * and comparing each byte individually. % + * % + * The expression [1,2]: % + * % + * (1) ~(((x & 0x7f....7f) + 0x7f....7f) | (x | 0x7f....7f)) % + * % + * evaluates to a non-zero value if any of the bytes in the % + * original word is zero. % ... This comment has some spelling errors and doesn't belong here. The algorithm is mostly general and should be described centrally. A more complicated variant of It is used without comment in memchr.S and strchr.S. Describing things in terms of PowerPC (?) clz instructions belongs even less in the i386 asm version than it does in a general comment. % Index: strncmp.S % =================================================================== % RCS file: strncmp.S % diff -N strncmp.S % --- /dev/null 1 Jan 1970 00:00:00 -0000 % +++ strncmp.S 1 Aug 2005 18:13:51 -0000 % @@ -0,0 +1,108 @@ Note as good as memchr.S. It uses an algorithm that apparently gives no better results than the generic C one, and uses meaningless though named labels throughout. % Index: strrchr.S % =================================================================== % RCS file: strrchr.S % diff -N strrchr.S % --- /dev/null 1 Jan 1970 00:00:00 -0000 % +++ strrchr.S 1 Aug 2005 18:15:07 -0000 % @@ -0,0 +1,127 @@ Similarly to strchr.S. but less worth optimizing. % Index: swab.S % =================================================================== % RCS file: swab.S % diff -N swab.S % --- /dev/null 1 Jan 1970 00:00:00 -0000 % +++ swab.S 1 Aug 2005 18:18:17 -0000 % @@ -0,0 +1,47 @@ Shows how not to optimize things. % +#define LOAD_SWAP_STORE_WORD \ % + lodsw ; \ The lods instruction should never be used, since it is very slow. % + xchgb %al,%ah ; \ Partial register operations should be avoided. I don't know if this is important on amd64's. On Athlons xchgb of 2 registers is on the VectorPath and takes 2 cycles, so is probably possible to do 2 byte loads to the right places (%al and %ah) in the same time that it takes to fix up the bytes after slowly loading them as a word, provided there is no penalty for the partial register operations. I think the C code wins by doing something similar. % + stosw stosw Is OK. % +L2: shrq $3,%rdx # copy remainder 8 words at a time % + jz L4 # while swapping alternate bytes. % +L3: % + LOAD_SWAP_STORE_WORD % + LOAD_SWAP_STORE_WORD % + LOAD_SWAP_STORE_WORD % + LOAD_SWAP_STORE_WORD % + LOAD_SWAP_STORE_WORD % + LOAD_SWAP_STORE_WORD % + LOAD_SWAP_STORE_WORD % + LOAD_SWAP_STORE_WORD % + % + decq %rdx % + jnz L3 To optimize the amd64 version, I would first try loading 8 bytes at a time and swap them using a minimal combination of bswaps and rotates. Bruce