From owner-freebsd-arch@FreeBSD.ORG Sun May 6 00:59:27 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B356516A401; Sun, 6 May 2007 00:59:27 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id 4EE4A13C46A; Sun, 6 May 2007 00:59:27 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout1.pacific.net.au (Postfix) with ESMTP id EF0FE5A07AE; Sun, 6 May 2007 10:59:25 +1000 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 10B2C27406; Sun, 6 May 2007 10:59:23 +1000 (EST) Date: Sun, 6 May 2007 10:59:23 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andrey Chernov In-Reply-To: <20070505221125.GA50439@nagual.pp.ru> Message-ID: <20070506091835.A43775@besplex.bde.org> References: <20070502183100.P1317@baba.farley.org> <20070502230413.Y30614@thor.farley.org> <20070503160351.GA15008@nagual.pp.ru> <20070504085905.J39482@thor.farley.org> <20070504213312.GA33163@nagual.pp.ru> <20070504174657.D1343@thor.farley.org> <20070505213202.GA49925@nagual.pp.ru> <20070505163707.J6670@thor.farley.org> <20070505221125.GA50439@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eischen , arch@freebsd.org, "Sean C. Farley" Subject: Re: HEADS DOWN 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: Sun, 06 May 2007 00:59:27 -0000 On Sun, 6 May 2007, Andrey Chernov wrote: > On Sat, May 05, 2007 at 04:48:44PM -0500, Sean C. Farley wrote: >> I have the same assembly output. Inlined __strleneq() ends up being >> faster on my system than GCC's strlen() when I changed all calls where >> checkEquals equaled false. I believe you that it should be faster with >> GCC's version, but it is not ending up that way on my Athlon XP and >> Pentium 4 systems running FreeBSD 6.2. >> >> There is now a sysenv-strlen.c that I tested the timings.c program in >> regressions/environment directory. It keeps showing __strleneq() to be >> faster. > > I wonder how it possible. Your after "if" variant becomes > .L13: > incl %eax > cmpb $0, (%eax) > jne .L13 > which should be slower in general than gcc ones. No, it should be faster on most machines. I just happened to look at an optimization manual which reminded me that most string instructions should never be used since they have large setup overheads and most of them are slower even after setup. I thought that scasb wasn't so bad, but the manual went as far as saying that scasb is one of the string instructions that should never be used. AthlonXP timing (execution latency) for some (repeated) string instructions (forward direction) (non-repeated string instructions are even less useful, and the reverse direction has even higher overheads): movs 15 + 4/3 *c can sometimes beat load-store stos 14 + 1 *c wastes up to 1/2 of store bandwidth lods 15 + 2 *c wastes up to 3/4 of load bandwidth scas 15 + 5/2 *c 1.25 times slower than the above simple loop cmps 16 + 10/3*c 10/4 times slower than a simple loop The setup overhead for using string instructions may be much larger than the 14-16 in the above table. It is also necessary to set the direction flag and maybe to shuffle registers so as to use the registers required by the string instructions. cld/std is fast enough on Athlons (1/2 cycles) but is slow on Pentium4 and later (IIRC, 43 cycles for std on one Pentium model). All simple loops like the above take only 2 cycles (execution latency) on many modern CPUs including Athlons. The memory compare takes 2 cycles (1 to load and 1 to compare). The loop overhead is also 2 cycles, but this executes in parallel. Athlons have 3 fairly independent pipelines, so all loops between an empty one and one doing twice as much non-loop-overhead work as the above execute in 2 cycles provided the work is sufficiently independent, and it may be possible to implement strlen() up to 3/2 times faster using a not-so simple loop while still using a byte-wise algorithm. Speeding it up like this isn't easy -- I can't think of anything better to do than cmpb of another byte, but the loop would need to be unrolled for this to work and then we would have a 16-bit-word-wise algorithm that has most of the disadvantages and few of the advantages of a 16/32/64-bit-word-wise algorithm. The simplest loop above is likely to be best for average strings since it low setup overhead and no special cases. gcc understands very little of this and still generates string instructions (gcc does know to issue the cld as early as possible so that its latency probably doesn't matter). Inlining strlen() using string instructions may still be both a space and time optimization relative to the extern version, but cannot compete with the simplest loop. THe FreeBSD string library understands only a little of this. The i386 part is full of string instructions that may have been good for original i386's (but which do things like non-rep string instructions that were probably always pessimizations). The amd64 part is smarter. It doesn't have strlen.S or special support for most str and mem functions, but it does have strcmp.S and of course memcmp.S. Its strcmp.S uses a 64-bit word-wise algorithm so it will probably beat the simple byte-wise algorithm; it probably doesn't need to be written in asm to do this, but many machine dependencies are involved in knowing that 64 bits can be used, and are best, and to know and use the best alignment. glibc-2.4 has tege's old code for the 32/64-bit word-wise algorithm for the generic strlen() in C, but the i386 version is "optimized" to use rep scasb like the gcc builtin. Of course, optimizing strlen() is unimportant, since even the slowest method runs at nearly 1GB/S on modern machines and you rarely have more than a few MB of strings to process. Bruce From owner-freebsd-arch@FreeBSD.ORG Sun May 6 03:45:43 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3EB9516A401; Sun, 6 May 2007 03:45:43 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp7.server.rpi.edu (smtp7.server.rpi.edu [128.113.2.227]) by mx1.freebsd.org (Postfix) with ESMTP id 9B46E13C45A; Sun, 6 May 2007 03:45:42 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp7.server.rpi.edu (8.13.1/8.13.1) with ESMTP id l462Wc0s031396; Sat, 5 May 2007 22:32:43 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <463BB88F.4020804@aueb.gr> References: <19235.1178303887@critter.freebsd.dk> <463BB88F.4020804@aueb.gr> Date: Sat, 5 May 2007 22:32:37 -0400 To: Diomidis Spinellis From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-RPI-SA-Score: undef - spam scanning disabled X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.227 Cc: arch@FreeBSD.org, re@FreeBSD.org Subject: Re: Accounting changes 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: Sun, 06 May 2007 03:45:43 -0000 At 1:49 AM +0300 5/5/07, Diomidis Spinellis wrote: >Poul-Henning Kamp wrote: >>In message <463B581E.6070804@aueb.gr>, Diomidis Spinellis writes: >> >>>On modern processors the various time values were 0, because many >>>commands took less than 1/64s to execute [bde]. Now time values >>>are stored with microsecond precision as float numbers.(I've >>>written code that allows the kernel to write them without any >>>floating point operations.) In http://www.spinellis.gr/FreeBSD/acct.h , there is a comment which says: * Time units are milliseconds. Is it milliseconds or microseconds? >>Why on earth introduce another time format ? >> >>Please use a standard time format please. > >If we use struct timeval for the three time values the structure >size increases considerably (especially on an amd64). Here are some >numbers: > >i386 >Old size=48 >New size=64 >New size with timeval=76 > >amd64 >Old size=56 >New size=72 >New size timeval=112 > >On a busy system this increase can be more than 10GB / month. Is >there some other standard time format I've missed? Looking at the current version of acct.h, it has a u_int16_t field, where the value stored is 1/64th of a second, and it's stored in a special floating-point format (ie, it is a format that we define, instead of using the native machine floating point). Does this mean the new accounting record will be using the native-hardware format for floating point numbers? Does that mean the records produced will be different for different hardware? How about going to an u_int32_t field for those three time fields, and again use a custom-defined format for the floating-point value? The main reason I suggest this is so we know the format will be exactly the same on all architectures. We could go with a 4-bit base-8 exponent (up from 3 bits in the current format), and still have 28 bits for the fractional-part. I also wonder about using a time_t for ac_btime (starting time). Now that we're running freebsd on very fast, multi-processor systems, we might care whether "-command" executed before "-command", and we might wish to have better resolution for the start-time of a given command. This is just an idle thought on my part though, and it is not something that I have a strong opinion on. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-arch@FreeBSD.ORG Sun May 6 04:50:45 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B17116A401 for ; Sun, 6 May 2007 04:50:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by mx1.freebsd.org (Postfix) with ESMTP id A046913C45B for ; Sun, 6 May 2007 04:50:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.227] (helo=fw.zoral.com.ua) by relay01.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1HkYhm-0006VA-KS; Sun, 06 May 2007 07:50:43 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id l464oRi8037268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 May 2007 07:50:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l464oR2J009925; Sun, 6 May 2007 07:50:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l464oPAx009924; Sun, 6 May 2007 07:50:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 6 May 2007 07:50:25 +0300 From: Kostik Belousov To: Bruce Evans Message-ID: <20070506045025.GB83173@deviant.kiev.zoral.com.ua> References: <20070502230413.Y30614@thor.farley.org> <20070503160351.GA15008@nagual.pp.ru> <20070504085905.J39482@thor.farley.org> <20070504213312.GA33163@nagual.pp.ru> <20070504174657.D1343@thor.farley.org> <20070505213202.GA49925@nagual.pp.ru> <20070505163707.J6670@thor.farley.org> <20070505221125.GA50439@nagual.pp.ru> <20070506091835.A43775@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dc+cDN39EJAMEtIO" Content-Disposition: inline In-Reply-To: <20070506091835.A43775@besplex.bde.org> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-0.1 required=5.0 tests=ALL_TRUSTED,SPF_NEUTRAL autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on fw.zoral.com.ua X-Scanner-Signature: d0b3bc0b24c4067239780ad28ae5b444 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1023 [May 04 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: Daniel Eischen , arch@freebsd.org, "Sean C. Farley" Subject: Re: HEADS DOWN 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: Sun, 06 May 2007 04:50:45 -0000 --dc+cDN39EJAMEtIO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, May 06, 2007 at 10:59:23AM +1000, Bruce Evans wrote: > The setup overhead for using string instructions may be much larger than > the 14-16 in the above table. It is also necessary to set the direction > flag and maybe to shuffle registers so as to use the registers required > by the string instructions. cld/std is fast enough on Athlons (1/2 > cycles) but is slow on Pentium4 and later (IIRC, 43 cycles for std on > one Pentium model). gcc 4.3 claims to not issue cld instruction anymore (ABI requires direction flag to be clear since eon). --dc+cDN39EJAMEtIO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGPV6RC3+MBN1Mb4gRAgURAJ9mPDQQwgypxPRE3xJ7WibUSt4RBQCfVeKi uKtSbZEXEcjK7PvW8qGTP8c= =gE3J -----END PGP SIGNATURE----- --dc+cDN39EJAMEtIO-- From owner-freebsd-arch@FreeBSD.ORG Sun May 6 09:06:09 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 08DC716A406; Sun, 6 May 2007 09:06:09 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-out-01.forthnet.gr (mx-out.forthnet.gr [193.92.150.103]) by mx1.freebsd.org (Postfix) with ESMTP id 7726113C484; Sun, 6 May 2007 09:06:08 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.13.8/8.13.8) with ESMTP id l46966Dp025171; Sun, 6 May 2007 12:06:06 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-04.forthnet.gr (8.14.1/8.14.1) with ESMTP id l46966ct020659; Sun, 6 May 2007 12:06:06 +0300 Received: from [192.168.136.22] (ppp124-213.adsl.forthnet.gr [193.92.231.213]) by MX-IN-01.forthnet.gr (8.14.1/8.14.1) with ESMTP id l46964ZT024887; Sun, 6 May 2007 12:06:05 +0300 Authentication-Results: MX-IN-01.forthnet.gr from=dds@aueb.gr; sender-id=neutral; spf=neutral Message-ID: <463D9A7A.1080800@aueb.gr> Date: Sun, 06 May 2007 12:06:02 +0300 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1 MIME-Version: 1.0 To: Garance A Drosehn References: <19235.1178303887@critter.freebsd.dk> <463BB88F.4020804@aueb.gr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, re@FreeBSD.org Subject: Re: Accounting changes 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: Sun, 06 May 2007 09:06:09 -0000 Garance A Drosehn wrote: > At 1:49 AM +0300 5/5/07, Diomidis Spinellis wrote: >> Poul-Henning Kamp wrote: >>> In message <463B581E.6070804@aueb.gr>, Diomidis Spinellis writes: >>> >>>> On modern processors the various time values were 0, because many >>>> commands took less than 1/64s to execute [bde]. Now time values are >>>> stored with microsecond precision as float numbers.(I've written >>>> code that allows the kernel to write them without any floating point >>>> operations.) > > In http://www.spinellis.gr/FreeBSD/acct.h , > there is a comment which says: > > * Time units are milliseconds. > > Is it milliseconds or microseconds? Microseconds; I've corrected it - thanks! > Looking at the current version of acct.h, it has a u_int16_t field, > where the value stored is 1/64th of a second, and it's stored in a > special floating-point format (ie, it is a format that we define, > instead of using the native machine floating point). > > Does this mean the new accounting record will be using the > native-hardware format for floating point numbers? Does that mean > the records produced will be different for different hardware? My intention is to use the standard (IEEE 754-1985 / IEEE 854-1987 / IEC 60559) 32-bit float format. This is the C "float" type on all the architectures we support. I could add a typedef clarifying this, but I doubt we'll ever support an architecture (VAX?) where float is a different format. > How about going to an u_int32_t field for those three time fields, > and again use a custom-defined format for the floating-point value? > The main reason I suggest this is so we know the format will be > exactly the same on all architectures. We could go with a 4-bit > base-8 exponent (up from 3 bits in the current format), and still > have 28 bits for the fractional-part. The 32-bit IEEE format is close to your suggestion: 32 bits; 24 significant binary digits (1 implied); 8 exponent bits. The advantage of the IEEE format is that userland utilities can interpret the records without further processing. We also avoid introducing another non-standard floating point format. Many years ago I wrote Perl code to interpret comp_t. It wasn't fun. > I also wonder about using a time_t for ac_btime (starting time). > Now that we're running freebsd on very fast, multi-processor systems, > we might care whether "-command" executed before "-command", > and we might wish to have better resolution for the start-time of a > given command. This is just an idle thought on my part though, and > it is not something that I have a strong opinion on. I don't have a strong opinion either. Let's see if others think whether using a struct timeval for ac_btime would be useful. Diomidis From owner-freebsd-arch@FreeBSD.ORG Sun May 6 10:10:27 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 82DE316A408 for ; Sun, 6 May 2007 10:10:27 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-3-125.belrs4.nsw.optusnet.com.au [220.239.3.125]) by mx1.freebsd.org (Postfix) with ESMTP id F3DC413C4CC for ; Sun, 6 May 2007 10:10:26 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l46AAKiJ004979; Sun, 6 May 2007 20:10:20 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l46AAK9r004978; Sun, 6 May 2007 20:10:20 +1000 (EST) (envelope-from peter) Date: Sun, 6 May 2007 20:10:20 +1000 From: Peter Jeremy To: Diomidis Spinellis Message-ID: <20070506101020.GL825@turion.vk2pj.dyndns.org> References: <19235.1178303887@critter.freebsd.dk> <463BB88F.4020804@aueb.gr> <463D9A7A.1080800@aueb.gr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uCPdOCrL+PnN2Vxy" Content-Disposition: inline In-Reply-To: <463D9A7A.1080800@aueb.gr> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.14 (2007-02-12) Cc: arch@freebsd.org, Garance A Drosehn Subject: Re: Accounting changes 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: Sun, 06 May 2007 10:10:27 -0000 --uCPdOCrL+PnN2Vxy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-May-06 12:06:02 +0300, Diomidis Spinellis wrote: >Garance A Drosehn wrote: >>Does this mean the new accounting record will be using the >>native-hardware format for floating point numbers? Does that mean >>the records produced will be different for different hardware? > >My intention is to use the standard (IEEE 754-1985 / IEEE 854-1987 / IEC= =20 >60559) 32-bit float format. This is the C "float" type on all the=20 >architectures we support. I could add a typedef clarifying this, but I=20 >doubt we'll ever support an architecture (VAX?) where float is a=20 >different format. IEEE-754 etc define how to interpret a 32-bit object as a floating point number. AFAIK, it does not define how that object is laid out in memory so that a float written on SPARC (big-endian) will be different to that written on an i386 (little-endian). Accounting records do not need all the features that a general FP format needs: - No need to support negative numbers - It is easy to define comp_t so there are no negative exponents - No need to support denormals - No need to support NaN - Supporting infinity is optional. This means that it's possible to define a format that is relatively easy to manipulate or convert into a "standard" C FP format. >>I also wonder about using a time_t for ac_btime (starting time). >>Now that we're running freebsd on very fast, multi-processor systems, >>we might care whether "-command" executed before "-command", >>and we might wish to have better resolution for the start-time of a >>given command. On a multi-processor machine, both commands may have begun at the same time (measured to whatever precision you want). There are occasional discussions regarding file timestamps (lack of precision can confuse make) - which is a related issue. The decision as to whether make ac_time a time_t or (eg) struct timespec is not obvious: There is a definite space disadvantage to increasing ac_time precision (though there's only one instance per accounting record so the problem isn't as serious as comp_t). OTOH, I can see theoretical reasons for wanting to know which command came first. This is probably a question that needs wider discussion: Has there been any request for greater precision within the FreeBSD user community? --=20 Peter Jeremy --uCPdOCrL+PnN2Vxy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGPamM/opHv/APuIcRAstHAJwJcziVPZDVoeZgM58mZ11vq2vdfQCfeKPf Q/IU5yS+ZerhrBy5jQCW0lg= =yegx -----END PGP SIGNATURE----- --uCPdOCrL+PnN2Vxy-- From owner-freebsd-arch@FreeBSD.ORG Sun May 6 10:16:18 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A855116A402; Sun, 6 May 2007 10:16:18 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id 6C6A113C48A; Sun, 6 May 2007 10:16:18 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id 41997119096; Sun, 6 May 2007 20:16:10 +1000 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id C012E8C09; Sun, 6 May 2007 20:16:15 +1000 (EST) Date: Sun, 6 May 2007 20:16:15 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Kostik Belousov In-Reply-To: <20070506045025.GB83173@deviant.kiev.zoral.com.ua> Message-ID: <20070506195805.S45282@besplex.bde.org> References: <20070502230413.Y30614@thor.farley.org> <20070503160351.GA15008@nagual.pp.ru> <20070504085905.J39482@thor.farley.org> <20070504213312.GA33163@nagual.pp.ru> <20070504174657.D1343@thor.farley.org> <20070505213202.GA49925@nagual.pp.ru> <20070505163707.J6670@thor.farley.org> <20070505221125.GA50439@nagual.pp.ru> <20070506091835.A43775@besplex.bde.org> <20070506045025.GB83173@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eischen , arch@freebsd.org, "Sean C. Farley" Subject: Re: HEADS DOWN 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: Sun, 06 May 2007 10:16:18 -0000 On Sun, 6 May 2007, Kostik Belousov wrote: > On Sun, May 06, 2007 at 10:59:23AM +1000, Bruce Evans wrote: >> The setup overhead for using string instructions may be much larger than >> the 14-16 in the above table. It is also necessary to set the direction >> flag and maybe to shuffle registers so as to use the registers required >> by the string instructions. cld/std is fast enough on Athlons (1/2 >> cycles) but is slow on Pentium4 and later (IIRC, 43 cycles for std on >> one Pentium model). > gcc 4.3 claims to not issue cld instruction anymore (ABI requires direction > flag to be clear since eon). Ha, the library for my compiler required this in 1988 (its ABI is supposed to be compatible with other compilers, and seemed to be compatible with several including gcc and 2 unusual ones). However, FreeBSD has never really supported this -- it doesn't touch the direction flag for signal handling. String functions don't seem to be required to be async signal-safe in draft POSIX.1-2001, but they should be in practice (when called on an string in local storage), and things like struct copies (to and from local variables) are required to work even for C90 signal handlers. Bruce From owner-freebsd-arch@FreeBSD.ORG Sun May 6 11:44:06 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D790516A402; Sun, 6 May 2007 11:44:06 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-out-01.forthnet.gr (mx-out.forthnet.gr [193.92.150.103]) by mx1.freebsd.org (Postfix) with ESMTP id 5221E13C45E; Sun, 6 May 2007 11:44:06 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.13.8/8.13.8) with ESMTP id l46Bi4s0023419; Sun, 6 May 2007 14:44:04 +0300 Received: from MX-IN-02.forthnet.gr (mx-in-02.forthnet.gr [193.92.150.185]) by mx-av-04.forthnet.gr (8.14.1/8.14.1) with ESMTP id l46Bi4tq024566; Sun, 6 May 2007 14:44:04 +0300 Received: from [192.168.136.22] (ppp124-213.adsl.forthnet.gr [193.92.231.213]) by MX-IN-02.forthnet.gr (8.14.1/8.14.1) with ESMTP id l46BhvCV000353; Sun, 6 May 2007 14:43:57 +0300 Authentication-Results: MX-IN-02.forthnet.gr from=dds@aueb.gr; sender-id=neutral; spf=neutral Message-ID: <463DBF7A.8070200@aueb.gr> Date: Sun, 06 May 2007 14:43:54 +0300 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1 MIME-Version: 1.0 To: Peter Jeremy References: <19235.1178303887@critter.freebsd.dk> <463BB88F.4020804@aueb.gr> <463D9A7A.1080800@aueb.gr> <20070506101020.GL825@turion.vk2pj.dyndns.org> In-Reply-To: <20070506101020.GL825@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Garance A Drosehn Subject: Re: Accounting changes 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: Sun, 06 May 2007 11:44:06 -0000 Peter Jeremy wrote: > On 2007-May-06 12:06:02 +0300, Diomidis Spinellis wrote: >> Garance A Drosehn wrote: >>> Does this mean the new accounting record will be using the >>> native-hardware format for floating point numbers? Does that mean >>> the records produced will be different for different hardware? >> My intention is to use the standard (IEEE 754-1985 / IEEE 854-1987 / IEC >> 60559) 32-bit float format. This is the C "float" type on all the >> architectures we support. I could add a typedef clarifying this, but I >> doubt we'll ever support an architecture (VAX?) where float is a >> different format. > > IEEE-754 etc define how to interpret a 32-bit object as a floating > point number. AFAIK, it does not define how that object is laid > out in memory so that a float written on SPARC (big-endian) will > be different to that written on an i386 (little-endian). IEEE-754 defines the order of bits in a number. The intention is to allow lexicographical comparison of (valid) floating point numbers, using the normal byte compare instructions. If you write a file with a float on a SPARC you can read it back correctly on an i386. However, given that the accounting record structure's layout differs between architectures, even this property is not something we depend on. > Accounting records do not need all the features that a general FP > format needs: > - No need to support negative numbers > - It is easy to define comp_t so there are no negative exponents > - No need to support denormals > - No need to support NaN > - Supporting infinity is optional. > > This means that it's possible to define a format that is relatively > easy to manipulate or convert into a "standard" C FP format. True, IEEE numbers provide more features than we need. At the kernel interface where we write them, the conversion routine simply doesn't support these features, because, as you correctly say, we don't need them. At the userland interface (lastcomm, sa) these features are provided at no cost by the processor hardware and the C library. By adopting IEEE 754 we waste the storage space of the bit used to indicate negative numbers. However, I find that the benefit of not introducing another format (phk complained about that), and being able to read the records into standard C floats outweighs this loss. Diomidis Spinellis - http://www.spinellis.gr From owner-freebsd-arch@FreeBSD.ORG Sun May 6 12:46:17 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E28116A407 for ; Sun, 6 May 2007 12:46:17 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 8D57613C45B for ; Sun, 6 May 2007 12:46:16 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-253-10-135.bredband.comhem.se ([83.253.10.135]:58961 helo=falcon.midgard.homeip.net) by ch-smtp01.sth.basefarm.net with smtp (Exim 4.66) (envelope-from ) id 1HkftJ-0006iR-3d for arch@freebsd.org; Sun, 06 May 2007 14:31:05 +0200 Received: (qmail 32433 invoked from network); 6 May 2007 14:31:02 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with SMTP; 6 May 2007 14:31:02 +0200 Received: (qmail 56452 invoked by uid 1001); 6 May 2007 14:31:02 +0200 Date: Sun, 6 May 2007 14:31:02 +0200 From: Erik Trulsson To: Diomidis Spinellis Message-ID: <20070506123102.GA56344@owl.midgard.homeip.net> Mail-Followup-To: Diomidis Spinellis , Peter Jeremy , arch@freebsd.org, Garance A Drosehn References: <19235.1178303887@critter.freebsd.dk> <463BB88F.4020804@aueb.gr> <463D9A7A.1080800@aueb.gr> <20070506101020.GL825@turion.vk2pj.dyndns.org> <463DBF7A.8070200@aueb.gr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <463DBF7A.8070200@aueb.gr> User-Agent: Mutt/1.5.14 (2007-02-12) X-ACL-Warn: Too high rate of unknown addresses received from you X-Scan-Result: No virus found in message 1HkftJ-0006iR-3d. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1HkftJ-0006iR-3d a00fd35e046cac4d28c517dafbc4c977 Cc: Garance A Drosehn , arch@freebsd.org Subject: Re: Accounting changes 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: Sun, 06 May 2007 12:46:17 -0000 On Sun, May 06, 2007 at 02:43:54PM +0300, Diomidis Spinellis wrote: > Peter Jeremy wrote: > >On 2007-May-06 12:06:02 +0300, Diomidis Spinellis wrote: > >>Garance A Drosehn wrote: > >>>Does this mean the new accounting record will be using the > >>>native-hardware format for floating point numbers? Does that mean > >>>the records produced will be different for different hardware? > >>My intention is to use the standard (IEEE 754-1985 / IEEE 854-1987 / IEC > >>60559) 32-bit float format. This is the C "float" type on all the > >>architectures we support. I could add a typedef clarifying this, but I > >>doubt we'll ever support an architecture (VAX?) where float is a > >>different format. > > > >IEEE-754 etc define how to interpret a 32-bit object as a floating > >point number. AFAIK, it does not define how that object is laid > >out in memory so that a float written on SPARC (big-endian) will > >be different to that written on an i386 (little-endian). > > IEEE-754 defines the order of bits in a number. The intention is to > allow lexicographical comparison of (valid) floating point numbers, > using the normal byte compare instructions. Not quite. They are defined in such a manner as to allow them to be lexicographically compared just as if they were integers. And just like integers the byte order can vary between different architectures. > If you write a file with a > float on a SPARC you can read it back correctly on an i386. No you can't. I just tested this to be certain. On a SPARC a 32-bit float with the value 3.14 is stored as the bytes (in hexadecimal notation): 40 48 f5 c3 On i386 the order is c3 f5 48 40 -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-arch@FreeBSD.ORG Sun May 6 12:56:32 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0357E16A407; Sun, 6 May 2007 12:56:32 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-out-01.forthnet.gr (mx-out.forthnet.gr [193.92.150.103]) by mx1.freebsd.org (Postfix) with ESMTP id 7075E13C4BD; Sun, 6 May 2007 12:56:31 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-av-02.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.13.8/8.13.8) with ESMTP id l46CuRZj006004; Sun, 6 May 2007 15:56:27 +0300 Received: from MX-IN-03.forthnet.gr (mx-in-03.forthnet.gr [193.92.150.26]) by mx-av-02.forthnet.gr (8.14.1/8.14.1) with ESMTP id l46CuRbv017497; Sun, 6 May 2007 15:56:27 +0300 Received: from [192.168.136.22] (ppp124-213.adsl.forthnet.gr [193.92.231.213]) by MX-IN-03.forthnet.gr (8.14.1/8.14.1) with ESMTP id l46CuJxp002483; Sun, 6 May 2007 15:56:19 +0300 Authentication-Results: MX-IN-03.forthnet.gr from=dds@aueb.gr; sender-id=neutral; spf=neutral Message-ID: <463DD070.6090204@aueb.gr> Date: Sun, 06 May 2007 15:56:16 +0300 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1 MIME-Version: 1.0 To: Diomidis Spinellis , Peter Jeremy , arch@freebsd.org, Garance A Drosehn References: <19235.1178303887@critter.freebsd.dk> <463BB88F.4020804@aueb.gr> <463D9A7A.1080800@aueb.gr> <20070506101020.GL825@turion.vk2pj.dyndns.org> <463DBF7A.8070200@aueb.gr> <20070506123102.GA56344@owl.midgard.homeip.net> In-Reply-To: <20070506123102.GA56344@owl.midgard.homeip.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Accounting changes 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: Sun, 06 May 2007 12:56:32 -0000 Erik Trulsson wrote: > On Sun, May 06, 2007 at 02:43:54PM +0300, Diomidis Spinellis wrote: >> Peter Jeremy wrote: >>> On 2007-May-06 12:06:02 +0300, Diomidis Spinellis wrote: >>>> Garance A Drosehn wrote: >>>>> Does this mean the new accounting record will be using the >>>>> native-hardware format for floating point numbers? Does that mean >>>>> the records produced will be different for different hardware? >>>> My intention is to use the standard (IEEE 754-1985 / IEEE 854-1987 / IEC >>>> 60559) 32-bit float format. This is the C "float" type on all the >>>> architectures we support. I could add a typedef clarifying this, but I >>>> doubt we'll ever support an architecture (VAX?) where float is a >>>> different format. >>> IEEE-754 etc define how to interpret a 32-bit object as a floating >>> point number. AFAIK, it does not define how that object is laid >>> out in memory so that a float written on SPARC (big-endian) will >>> be different to that written on an i386 (little-endian). >> IEEE-754 defines the order of bits in a number. The intention is to >> allow lexicographical comparison of (valid) floating point numbers, >> using the normal byte compare instructions. > > Not quite. They are defined in such a manner as to allow them to be > lexicographically compared just as if they were integers. And just like > integers the byte order can vary between different architectures. > > >> If you write a file with a >> float on a SPARC you can read it back correctly on an i386. > > No you can't. I just tested this to be certain. > On a SPARC a 32-bit float with the value 3.14 is stored as the bytes (in > hexadecimal notation): > 40 48 f5 c3 > > On i386 the order is > c3 f5 48 40 You're right - my mistake. (I also tested this before posting (concidentally with 3.1415), but I botched when I converted the program I used for writing data on the SPARC into the program that read data on the i386 :-) Diomidis Spinellis From owner-freebsd-arch@FreeBSD.ORG Sun May 6 23:58:16 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A780316A403 for ; Sun, 6 May 2007 23:58:16 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp6.server.rpi.edu (smtp6.server.rpi.edu [128.113.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id 6E0A013C45E for ; Sun, 6 May 2007 23:58:16 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp6.server.rpi.edu (8.13.1/8.13.1) with ESMTP id l46Nw4dL005423; Sun, 6 May 2007 19:58:08 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20070506101020.GL825@turion.vk2pj.dyndns.org> References: <19235.1178303887@critter.freebsd.dk> <463BB88F.4020804@aueb.gr> <463D9A7A.1080800@aueb.gr> <20070506101020.GL825@turion.vk2pj.dyndns.org> Date: Sun, 6 May 2007 19:58:03 -0400 To: Peter Jeremy , Diomidis Spinellis From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-RPI-SA-Score: undef - spam scanning disabled X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.226 Cc: arch@FreeBSD.org Subject: Re: Accounting changes 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: Sun, 06 May 2007 23:58:16 -0000 At 8:10 PM +1000 5/6/07, Peter Jeremy wrote: > > Garance A Drosehn wrote: > >>>I also wonder about using a time_t for ac_btime (starting time). >>>Now that we're running freebsd on very fast, multi-processor systems, >>>we might care whether "-command" executed before "-command", >>>and we might wish to have better resolution for the start-time of a >>>given command. > >On a multi-processor machine, both commands may have begun at the >same time (measured to whatever precision you want). Hmm. Well, that is a good point... >There are >occasional discussions regarding file timestamps (lack of precision >can confuse make) - which is a related issue. The decision as to >whether make ac_time a time_t or (eg) struct timespec is not obvious: >There is a definite space disadvantage to increasing ac_time precision >(though there's only one instance per accounting record so the problem >isn't as serious as comp_t). OTOH, I can see theoretical reasons for >wanting to know which command came first. > >This is probably a question that needs wider discussion: Has there >been any request for greater precision within the FreeBSD user >community? Not that I know of, but it might be that everyone is so used to the current resolution that they don't think much about changing it. Recently I have had a few cases where I was debugging something, and I did need time-resolution better than the nearest second. Admittedly those cases had nothing to do with these accounting records. However, I have had three separate cases where I've needed this in the past six months or so, and I don't think I've ever needed sub-second resolution before that. I don't know that we need better resolution for this version of the accounting-record format, but I suspect we will want it at some point in the future. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-arch@FreeBSD.ORG Mon May 7 20:38:33 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA16316A401 for ; Mon, 7 May 2007 20:38:33 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 3B8BC13C457 for ; Mon, 7 May 2007 20:38:32 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l47KKrNV025259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 May 2007 23:20:59 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l47KKZYQ087946; Mon, 7 May 2007 23:20:47 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l47KKYdj087945; Mon, 7 May 2007 23:20:34 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Mon, 7 May 2007 23:20:34 +0300 From: Giorgos Keramidas To: Hans Petter Selasky Message-ID: <20070507202034.GA80846@kobe.laptop> References: <200705051617.34162.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200705051617.34162.hselasky@c2i.net> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.811, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.59, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-arch@freebsd.org Subject: Re: Missing LIST_PREV() ? 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, 07 May 2007 20:38:33 -0000 On 2007-05-05 16:17, Hans Petter Selasky wrote: > Hi, > > Why should LISTs only be forward traversable? The following piece of code make > lists backward traversable: > > /sys/sys/queue.h: > > +#define LIST_PREV(head,elm,field) \ > + (((elm) == LIST_FIRST(head)) ? ((__typeof(elm))0) : \ > + ((__typeof(elm))(((uint8_t *)((elm)->field.le_prev)) - \ > + ((uint8_t *)&LIST_NEXT((__typeof(elm))0,field))))) > > Any comments? 1. The use of (uint8_t *) casts is relatively ugly. 2. What does LIST_PREV give us that cannot be done with TAILQ_PREV() already? From owner-freebsd-arch@FreeBSD.ORG Mon May 7 20:38:35 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C83316A402 for ; Mon, 7 May 2007 20:38:35 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 9A69713C447 for ; Mon, 7 May 2007 20:38:34 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l47KPcXP025429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 May 2007 23:25:43 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l47KPJXN088693; Mon, 7 May 2007 23:25:31 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l47KPISm088692; Mon, 7 May 2007 23:25:18 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Mon, 7 May 2007 23:25:18 +0300 From: Giorgos Keramidas To: Hans Petter Selasky Message-ID: <20070507202517.GA88340@kobe.laptop> References: <200705051617.34162.hselasky@c2i.net> <20070507202034.GA80846@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070507202034.GA80846@kobe.laptop> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.812, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.59, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-arch@freebsd.org Subject: Re: Missing LIST_PREV() ? 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, 07 May 2007 20:38:35 -0000 On 2007-05-07 23:20, Giorgos Keramidas wrote: >On 2007-05-05 16:17, Hans Petter Selasky wrote: >> Hi, >> >> Why should LISTs only be forward traversable? The following piece of >> code make lists backward traversable: >> >> /sys/sys/queue.h: >> >> +#define LIST_PREV(head,elm,field) \ >> + (((elm) == LIST_FIRST(head)) ? ((__typeof(elm))0) : \ >> + ((__typeof(elm))(((uint8_t *)((elm)->field.le_prev)) - \ >> + ((uint8_t *)&LIST_NEXT((__typeof(elm))0,field))))) >> >> Any comments? > > 1. The use of (uint8_t *) casts is relatively ugly. > > 2. What does LIST_PREV give us that cannot be done with TAILQ_PREV() > already? Even more importantly, which I missed in my original look (3) The use of the gcc-specific __typeof() extension makes this unusable with other compilers. The entire header is otherwise very portable and I already use it successfully on other systems too (i.e. Solaris with the Sun Studio 11 compilers). Introducing unportable constructs like __typeof() shouldn't be allowed, IMHO. - Giorgos From owner-freebsd-arch@FreeBSD.ORG Tue May 8 17:55:23 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 44CCB16A403; Tue, 8 May 2007 17:55:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id C726313C465; Tue, 8 May 2007 17:55:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l48HtC22085124; Tue, 8 May 2007 13:55:13 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Tue, 8 May 2007 11:28:25 -0400 User-Agent: KMail/1.9.6 References: <200705051617.34162.hselasky@c2i.net> <20070507202034.GA80846@kobe.laptop> <20070507202517.GA88340@kobe.laptop> In-Reply-To: <20070507202517.GA88340@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200705081128.25708.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 08 May 2007 13:55:13 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3222/Tue May 8 11:43:01 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Giorgos Keramidas , Hans Petter Selasky Subject: Re: Missing LIST_PREV() ? 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, 08 May 2007 17:55:23 -0000 On Monday 07 May 2007 04:25:18 pm Giorgos Keramidas wrote: > On 2007-05-07 23:20, Giorgos Keramidas wrote: > >On 2007-05-05 16:17, Hans Petter Selasky wrote: > >> Hi, > >> > >> Why should LISTs only be forward traversable? The following piece of > >> code make lists backward traversable: > >> > >> /sys/sys/queue.h: > >> > >> +#define LIST_PREV(head,elm,field) \ > >> + (((elm) == LIST_FIRST(head)) ? ((__typeof(elm))0) : \ > >> + ((__typeof(elm))(((uint8_t *)((elm)->field.le_prev)) - \ > >> + ((uint8_t *)&LIST_NEXT((__typeof(elm))0,field))))) > >> > >> Any comments? > > > > 1. The use of (uint8_t *) casts is relatively ugly. Looks like an ugly version of offsetof() > > 2. What does LIST_PREV give us that cannot be done with TAILQ_PREV() > > already? > > Even more importantly, which I missed in my original look > > (3) The use of the gcc-specific __typeof() extension makes this unusable > with other compilers. This can be fixed by passing the type as an argument which is what TAILQ_PREV() does: #define TAILQ_PREV(elm, headname, field) \ (*(((struct headname *)((elm)->field.tqe_prev))->tqh_last)) I'm not sure how portable offsetof() would be though. In general if you want this feature, you should just use a TAILQ though. TAILQ_ENTRY() is the same size as a LIST_ENTRY(), it just adds one more pointer to the HEAD structure. It is also specifically designed to make TAILQ_PREV() work w/o needing the offsetof() hack. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue May 8 18:45:06 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F352716A400 for ; Tue, 8 May 2007 18:45:05 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outX.internet-mail-service.net (outX.internet-mail-service.net [216.240.47.247]) by mx1.freebsd.org (Postfix) with ESMTP id DF67413C458 for ; Tue, 8 May 2007 18:45:05 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 08 May 2007 11:45:05 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 0131C125B43; Tue, 8 May 2007 11:45:03 -0700 (PDT) Message-ID: <4640C52E.7010209@elischer.org> Date: Tue, 08 May 2007 11:45:02 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: John Baldwin References: <200705051617.34162.hselasky@c2i.net> <20070507202034.GA80846@kobe.laptop> <20070507202517.GA88340@kobe.laptop> <200705081128.25708.jhb@freebsd.org> In-Reply-To: <200705081128.25708.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hans Petter Selasky , Giorgos Keramidas , freebsd-arch@freebsd.org Subject: Re: Missing LIST_PREV() ? 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, 08 May 2007 18:45:06 -0000 John Baldwin wrote: > On Monday 07 May 2007 04:25:18 pm Giorgos Keramidas wrote: >> with other compilers. > > This can be fixed by passing the type as an argument which is what > TAILQ_PREV() does: > > #define TAILQ_PREV(elm, headname, field) \ > (*(((struct headname *)((elm)->field.tqe_prev))->tqh_last)) > > I'm not sure how portable offsetof() would be though. In general if you want > this feature, you should just use a TAILQ though. TAILQ_ENTRY() is the same > size as a LIST_ENTRY(), it just adds one more pointer to the HEAD structure. > It is also specifically designed to make TAILQ_PREV() work w/o needing the > offsetof() hack. > I agree with this.. that's why we have the different types. The suggested change in ingenious but I don't know how portable it is.. From owner-freebsd-arch@FreeBSD.ORG Tue May 8 19:01:12 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 368F616A407 for ; Tue, 8 May 2007 19:01:12 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe10.swip.net [212.247.155.33]) by mx1.freebsd.org (Postfix) with ESMTP id 717CE13C447 for ; Tue, 8 May 2007 19:01:11 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.71.38.142] (account mc467741@c2i.net HELO [192.168.1.106]) by mailfe10.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 314453130; Tue, 08 May 2007 21:01:06 +0200 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Tue, 8 May 2007 21:00:51 +0200 User-Agent: KMail/1.9.5 References: <200705051617.34162.hselasky@c2i.net> <200705081128.25708.jhb@freebsd.org> <4640C52E.7010209@elischer.org> In-Reply-To: <4640C52E.7010209@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200705082100.51354.hselasky@c2i.net> Cc: Julian Elischer , Giorgos Keramidas Subject: Re: Missing LIST_PREV() ? 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, 08 May 2007 19:01:12 -0000 On Tuesday 08 May 2007 20:45, Julian Elischer wrote: > John Baldwin wrote: > > On Monday 07 May 2007 04:25:18 pm Giorgos Keramidas wrote: > >> with other compilers. > > > > This can be fixed by passing the type as an argument which is what > > TAILQ_PREV() does: > > > > #define TAILQ_PREV(elm, headname, field) = \ > > (*(((struct headname *)((elm)->field.tqe_prev))->tqh_last)) > > > > I'm not sure how portable offsetof() would be though. In general if you > > want this feature, you should just use a TAILQ though. TAILQ_ENTRY() is > > the same size as a LIST_ENTRY(), it just adds one more pointer to the > > HEAD structure. It is also specifically designed to make TAILQ_PREV() > > work w/o needing the offsetof() hack. > > I agree with this.. that's why we have the different types. > The suggested change in ingenious but I don't know how portable it is.. I suggested the following at hacker's: #define LIST_PREV(head,elm,field,type) \ =A0(((elm) =3D=3D LIST_FIRST(head)) ? ((struct type *)0) : \ =A0 ((struct type *)(((uint8_t *)((elm)->field.le_prev)) - \ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0((uint8_t *)&LIST_NEXT((struct type = *)0,field))))) What do you think? =2D-HPS From owner-freebsd-arch@FreeBSD.ORG Tue May 8 19:48:23 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8CF1D16A407 for ; Tue, 8 May 2007 19:48:23 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outS.internet-mail-service.net (outS.internet-mail-service.net [216.240.47.242]) by mx1.freebsd.org (Postfix) with ESMTP id 7A3BF13C459 for ; Tue, 8 May 2007 19:48:23 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 08 May 2007 12:48:23 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id BB169125A26; Tue, 8 May 2007 12:48:22 -0700 (PDT) Message-ID: <4640D404.6040204@elischer.org> Date: Tue, 08 May 2007 12:48:20 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Hans Petter Selasky References: <200705051617.34162.hselasky@c2i.net> <200705081128.25708.jhb@freebsd.org> <4640C52E.7010209@elischer.org> <200705082100.51354.hselasky@c2i.net> In-Reply-To: <200705082100.51354.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Giorgos Keramidas , freebsd-arch@freebsd.org Subject: Re: Missing LIST_PREV() ? 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, 08 May 2007 19:48:23 -0000 Hans Petter Selasky wrote: > On Tuesday 08 May 2007 20:45, Julian Elischer wrote: >> John Baldwin wrote: >>> On Monday 07 May 2007 04:25:18 pm Giorgos Keramidas wrote: >>>> with other compilers. >>> This can be fixed by passing the type as an argument which is what >>> TAILQ_PREV() does: >>> >>> #define TAILQ_PREV(elm, headname, field) \ >>> (*(((struct headname *)((elm)->field.tqe_prev))->tqh_last)) >>> >>> I'm not sure how portable offsetof() would be though. In general if you >>> want this feature, you should just use a TAILQ though. TAILQ_ENTRY() is >>> the same size as a LIST_ENTRY(), it just adds one more pointer to the >>> HEAD structure. It is also specifically designed to make TAILQ_PREV() >>> work w/o needing the offsetof() hack. >> I agree with this.. that's why we have the different types. >> The suggested change in ingenious but I don't know how portable it is.. > > I suggested the following at hacker's: > > #define LIST_PREV(head,elm,field,type) \ > (((elm) == LIST_FIRST(head)) ? ((struct type *)0) : \ > ((struct type *)(((uint8_t *)((elm)->field.le_prev)) - \ > ((uint8_t *)&LIST_NEXT((struct type *)0,field))))) > > What do you think? > > --HPS > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" I think I'd rather use offsetof() with a #ifdef offsetof around it. and a comment saying that if you are using this you probably should be using a TAILQ. The question is "should we, just because we can?" From owner-freebsd-arch@FreeBSD.ORG Tue May 8 20:58:53 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8589316A402; Tue, 8 May 2007 20:58:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 2EDE813C469; Tue, 8 May 2007 20:58:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l48Kwfqq086157; Tue, 8 May 2007 16:58:42 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Hans Petter Selasky Date: Tue, 8 May 2007 16:58:37 -0400 User-Agent: KMail/1.9.6 References: <200705051617.34162.hselasky@c2i.net> <4640C52E.7010209@elischer.org> <200705082100.51354.hselasky@c2i.net> In-Reply-To: <200705082100.51354.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200705081658.38171.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 08 May 2007 16:58:42 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3222/Tue May 8 11:43:01 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Giorgos Keramidas , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Missing LIST_PREV() ? 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, 08 May 2007 20:58:53 -0000 On Tuesday 08 May 2007 03:00:51 pm Hans Petter Selasky wrote: > On Tuesday 08 May 2007 20:45, Julian Elischer wrote: > > John Baldwin wrote: > > > On Monday 07 May 2007 04:25:18 pm Giorgos Keramidas wrote: > > >> with other compilers. > > > > > > This can be fixed by passing the type as an argument which is what > > > TAILQ_PREV() does: > > > > > > #define TAILQ_PREV(elm, headname, field) = =20 \ > > > (*(((struct headname *)((elm)->field.tqe_prev))->tqh_last)) > > > > > > I'm not sure how portable offsetof() would be though. In general if = you > > > want this feature, you should just use a TAILQ though. TAILQ_ENTRY()= is > > > the same size as a LIST_ENTRY(), it just adds one more pointer to the > > > HEAD structure. It is also specifically designed to make TAILQ_PREV() > > > work w/o needing the offsetof() hack. > > > > I agree with this.. that's why we have the different types. > > The suggested change in ingenious but I don't know how portable it is.. >=20 > I suggested the following at hacker's: >=20 > #define LIST_PREV(head,elm,field,type) \ > =A0(((elm) =3D=3D LIST_FIRST(head)) ? ((struct type *)0) : \ > =A0 ((struct type *)(((uint8_t *)((elm)->field.le_prev)) - \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0((uint8_t *)&LIST_NEXT((struct typ= e *)0,field))))) >=20 > What do you think? Just use a TAILQ, that's what it is there for. =2D-=20 John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue May 8 21:19:27 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3ECFE16A407 for ; Tue, 8 May 2007 21:19:27 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id ACAE113C45A for ; Tue, 8 May 2007 21:19:26 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l48L85q2016833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 May 2007 00:08:12 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l48L7kK2017991; Wed, 9 May 2007 00:07:59 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l48L7k19017990; Wed, 9 May 2007 00:07:46 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Wed, 9 May 2007 00:07:46 +0300 From: Giorgos Keramidas To: John Baldwin Message-ID: <20070508210745.GA17259@kobe.laptop> References: <200705051617.34162.hselasky@c2i.net> <4640C52E.7010209@elischer.org> <200705082100.51354.hselasky@c2i.net> <200705081658.38171.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200705081658.38171.jhb@freebsd.org> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.521, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.68, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-arch@freebsd.org, Julian Elischer , Hans Petter Selasky Subject: Re: Missing LIST_PREV() ? 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, 08 May 2007 21:19:27 -0000 On 2007-05-08 16:58, John Baldwin wrote: > On Tuesday 08 May 2007 03:00:51 pm Hans Petter Selasky wrote: > > I suggested the following at hacker's: > > > > #define LIST_PREV(head,elm,field,type) \ > >  (((elm) == LIST_FIRST(head)) ? ((struct type *)0) : \ > >   ((struct type *)(((uint8_t *)((elm)->field.le_prev)) - \ > >                    ((uint8_t *)&LIST_NEXT((struct type *)0,field))))) > > > > What do you think? > > Just use a TAILQ, that's what it is there for. The macro is interesting, but I wouldn't feel safe using it. I didn't receive the hackers post, but I fully agree. Please just use TAILQ. No pointer-hacks are needed, it's there already, it works as expected on all the cases I've seen... what more do we need? From owner-freebsd-arch@FreeBSD.ORG Tue May 8 21:36:14 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5875216A407; Tue, 8 May 2007 21:36:14 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 0A75F13C458; Tue, 8 May 2007 21:36:13 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from [192.168.1.211] ([192.168.1.211]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l48LbbIt005202; Tue, 8 May 2007 16:37:43 -0500 (CDT) (envelope-from sean-freebsd@farley.org) Date: Tue, 8 May 2007 16:37:03 -0500 (CDT) From: "Sean C. Farley" To: Bruce Evans In-Reply-To: <20070506091835.A43775@besplex.bde.org> Message-ID: <20070508162458.G6015@baba.farley.org> References: <20070502183100.P1317@baba.farley.org> <20070502230413.Y30614@thor.farley.org> <20070503160351.GA15008@nagual.pp.ru> <20070504085905.J39482@thor.farley.org> <20070504213312.GA33163@nagual.pp.ru> <20070504174657.D1343@thor.farley.org> <20070505213202.GA49925@nagual.pp.ru> <20070505163707.J6670@thor.farley.org> <20070505221125.GA50439@nagual.pp.ru> <20070506091835.A43775@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eischen , arch@freebsd.org Subject: Re: HEADS DOWN 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, 08 May 2007 21:36:14 -0000 On Sun, 6 May 2007, Bruce Evans wrote: > On Sun, 6 May 2007, Andrey Chernov wrote: > >> On Sat, May 05, 2007 at 04:48:44PM -0500, Sean C. Farley wrote: >>> I have the same assembly output. Inlined __strleneq() ends up >>> being faster on my system than GCC's strlen() when I changed all >>> calls where checkEquals equaled false. I believe you that it >>> should be faster with GCC's version, but it is not ending up that >>> way on my Athlon XP and Pentium 4 systems running FreeBSD 6.2. >>> >>> There is now a sysenv-strlen.c that I tested the timings.c program >>> in regressions/environment directory. It keeps showing >>> __strleneq() to be faster. >> >> I wonder how it possible. Your after "if" variant becomes >> .L13: >> incl %eax >> cmpb $0, (%eax) >> jne .L13 >> which should be slower in general than gcc ones. > > No, it should be faster on most machines. I just happened to look at > an optimization manual which reminded me that most string instructions > should never be used since they have large setup overheads and most of > them are slower even after setup. I thought that scasb wasn't so bad, > but the manual went as far as saying that scasb is one of the string > instructions that should never be used. > Of course, optimizing strlen() is unimportant, since even the slowest > method runs at nearly 1GB/S on modern machines and you rarely have > more than a few MB of strings to process. Here is a comparison of running setenv(name, value, 1) 1000 times before and after using strlen (when not looking for an '=' character) and inlined strlen respectively: x setenv-strlen-1000.txt + setenv-inline-1000.txt +--------------------------------------------------------------------------+ | + x x | | + +++ x x | | + +++ + x x x x| ||____MA_____| |__MA____| | +--------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 10 0.000256 0.000279 0.0002585 0.0002604 6.9474216e-06 + 10 0.000175 0.000206 0.0001785 0.0001808 9.0283504e-06 Difference at 95.0% confidence -7.96e-05 +/- 7.56879e-06 -30.5684% +/- 2.9066% (Student's t, pooled s = 8.05536e-06) There is a nice decrease in time using inline'ing and setenv() over strlen(). Would it be preferred to go ahead to use strlen() in preparation for a faster strlen() in the future? I would still use the inline'd version when counting characters while watching for an '=' character. Or should it also be changed to perform a strlen() and then a strchr()? Sean -- sean-freebsd@farley.org From owner-freebsd-arch@FreeBSD.ORG Tue May 8 21:39:01 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 44D7E16A402 for ; Tue, 8 May 2007 21:39:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by mx1.freebsd.org (Postfix) with ESMTP id DE92D13C43E for ; Tue, 8 May 2007 21:39:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.227] (helo=fw.zoral.com.ua) by relay01.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1HlX3i-000Pid-Nv; Wed, 09 May 2007 00:17:23 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id l48LHEUu055947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 May 2007 00:17:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l48LHEfc061080; Wed, 9 May 2007 00:17:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l48LHELx061079; Wed, 9 May 2007 00:17:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 9 May 2007 00:17:14 +0300 From: Kostik Belousov To: John Baldwin Message-ID: <20070508211714.GQ83173@deviant.kiev.zoral.com.ua> References: <200705051617.34162.hselasky@c2i.net> <20070507202034.GA80846@kobe.laptop> <20070507202517.GA88340@kobe.laptop> <200705081128.25708.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SlnaBQtdWG0gYnqZ" Content-Disposition: inline In-Reply-To: <200705081128.25708.jhb@freebsd.org> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-0.1 required=5.0 tests=ALL_TRUSTED,SPF_NEUTRAL autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on fw.zoral.com.ua X-Scanner-Signature: 1118cf21f7425d415ed61e91afc5cb63 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1030 [May 08 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: Hans Petter Selasky , Giorgos Keramidas , freebsd-arch@freebsd.org Subject: Re: Missing LIST_PREV() ? 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, 08 May 2007 21:39:01 -0000 --SlnaBQtdWG0gYnqZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 08, 2007 at 11:28:25AM -0400, John Baldwin wrote: > On Monday 07 May 2007 04:25:18 pm Giorgos Keramidas wrote: > > On 2007-05-07 23:20, Giorgos Keramidas wrote: > > >On 2007-05-05 16:17, Hans Petter Selasky wrote: > > >> Hi, > > >> > > >> Why should LISTs only be forward traversable? The following piece of > > >> code make lists backward traversable: > > >> > > >> /sys/sys/queue.h: > > >> > > >> +#define LIST_PREV(head,elm,field) \ > > >> + (((elm) =3D=3D LIST_FIRST(head)) ? ((__typeof(elm))0) : \ > > >> + ((__typeof(elm))(((uint8_t *)((elm)->field.le_prev)) - \ > > >> + ((uint8_t *)&LIST_NEXT((__typeof(elm))0,field)))= )) > > >> > > >> Any comments? > > > > > > 1. The use of (uint8_t *) casts is relatively ugly. >=20 > Looks like an ugly version of offsetof() >=20 =2E.. > I'm not sure how portable offsetof() would be though. In general if you = want=20 offsetof() itself is defined by C standard to be present both in freestanding and hosted environment (and be available by stddef.h). --SlnaBQtdWG0gYnqZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGQOjZC3+MBN1Mb4gRAvY/AJ9BnvqZFfK0UeYzO5dbnOasyent3wCeMLfE wodA2mOekcCVFOA5BnW/FB0= =8kZi -----END PGP SIGNATURE----- --SlnaBQtdWG0gYnqZ-- From owner-freebsd-arch@FreeBSD.ORG Tue May 8 21:51:44 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C71D16A402 for ; Tue, 8 May 2007 21:51:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outL.internet-mail-service.net (outL.internet-mail-service.net [216.240.47.235]) by mx1.freebsd.org (Postfix) with ESMTP id 677FA13C45E for ; Tue, 8 May 2007 21:51:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 08 May 2007 14:51:44 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id AAD6F125A24; Tue, 8 May 2007 14:51:43 -0700 (PDT) Message-ID: <4640F0EE.2080206@elischer.org> Date: Tue, 08 May 2007 14:51:42 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Kostik Belousov References: <200705051617.34162.hselasky@c2i.net> <20070507202034.GA80846@kobe.laptop> <20070507202517.GA88340@kobe.laptop> <200705081128.25708.jhb@freebsd.org> <20070508211714.GQ83173@deviant.kiev.zoral.com.ua> In-Reply-To: <20070508211714.GQ83173@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org, Giorgos Keramidas , Hans Petter Selasky Subject: Re: Missing LIST_PREV() ? 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, 08 May 2007 21:51:44 -0000 Kostik Belousov wrote: > On Tue, May 08, 2007 at 11:28:25AM -0400, John Baldwin wrote: >> On Monday 07 May 2007 04:25:18 pm Giorgos Keramidas wrote: >>> On 2007-05-07 23:20, Giorgos Keramidas wrote: >>>> On 2007-05-05 16:17, Hans Petter Selasky wrote: >>>>> Hi, >>>>> >>>>> Why should LISTs only be forward traversable? The following piece of >>>>> code make lists backward traversable: >>>>> >>>>> /sys/sys/queue.h: >>>>> >>>>> +#define LIST_PREV(head,elm,field) \ >>>>> + (((elm) == LIST_FIRST(head)) ? ((__typeof(elm))0) : \ >>>>> + ((__typeof(elm))(((uint8_t *)((elm)->field.le_prev)) - \ >>>>> + ((uint8_t *)&LIST_NEXT((__typeof(elm))0,field))))) >>>>> >>>>> Any comments? >>>> 1. The use of (uint8_t *) casts is relatively ugly. >> Looks like an ugly version of offsetof() >> > ... >> I'm not sure how portable offsetof() would be though. In general if you want > > offsetof() itself is defined by C standard to be present both in > freestanding and hosted environment (and be available by stddef.h). You learn something every day! interesting (but still scary).. From owner-freebsd-arch@FreeBSD.ORG Tue May 8 22:25:41 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 126B616A404; Tue, 8 May 2007 22:25:41 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 8D07713C4BA; Tue, 8 May 2007 22:25:40 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l48MPPMn060001; Wed, 9 May 2007 02:25:25 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l48MPOWA060000; Wed, 9 May 2007 02:25:24 +0400 (MSD) (envelope-from ache) Date: Wed, 9 May 2007 02:25:22 +0400 From: Andrey Chernov To: "Sean C. Farley" Message-ID: <20070508222521.GA59534@nagual.pp.ru> References: <20070502230413.Y30614@thor.farley.org> <20070503160351.GA15008@nagual.pp.ru> <20070504085905.J39482@thor.farley.org> <20070504213312.GA33163@nagual.pp.ru> <20070504174657.D1343@thor.farley.org> <20070505213202.GA49925@nagual.pp.ru> <20070505163707.J6670@thor.farley.org> <20070505221125.GA50439@nagual.pp.ru> <20070506091835.A43775@besplex.bde.org> <20070508162458.G6015@baba.farley.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070508162458.G6015@baba.farley.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Daniel Eischen , arch@freebsd.org Subject: Re: HEADS DOWN 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, 08 May 2007 22:25:41 -0000 On Tue, May 08, 2007 at 04:37:03PM -0500, Sean C. Farley wrote: > Would it be preferred to go ahead to use strlen() in preparation for a > faster strlen() in the future? IMHO with this note from Bruce "Of course, optimizing strlen() is unimportant, since even the slowest method runs at nearly 1GB/S on modern machines and you rarely have more than a few MB of strings to process." and this one from Kostik "gcc 4.3 claims to not issue cld instruction anymore (ABI requires direction flag to be clear since eon)." we can use strlen() in preparation for the future. > I would still use the inline'd version > when counting characters while watching for an '=' character. Or should > it also be changed to perform a strlen() and then a strchr()? Combined strlen()+strchr() will be slower in any case than single loop, so better leave it as is. -- http://ache.pp.ru/ From owner-freebsd-arch@FreeBSD.ORG Wed May 9 09:59:40 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7957616A404; Wed, 9 May 2007 09:59:40 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id 3E9B113C455; Wed, 9 May 2007 09:59:40 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id C43235AFFCC; Wed, 9 May 2007 19:59:38 +1000 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id A3D668C3F; Wed, 9 May 2007 19:59:37 +1000 (EST) Date: Wed, 9 May 2007 19:59:37 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Julian Elischer In-Reply-To: <4640F0EE.2080206@elischer.org> Message-ID: <20070509194746.F56462@besplex.bde.org> References: <200705051617.34162.hselasky@c2i.net> <20070507202034.GA80846@kobe.laptop> <20070507202517.GA88340@kobe.laptop> <200705081128.25708.jhb@freebsd.org> <20070508211714.GQ83173@deviant.kiev.zoral.com.ua> <4640F0EE.2080206@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , Hans Petter Selasky , Giorgos Keramidas , freebsd-arch@FreeBSD.org Subject: Re: Missing LIST_PREV() ? 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, 09 May 2007 09:59:40 -0000 On Tue, 8 May 2007, Julian Elischer wrote: > Kostik Belousov wrote: >> On Tue, May 08, 2007 at 11:28:25AM -0400, John Baldwin wrote: >>> I'm not sure how portable offsetof() would be though. In general if you >>> want >> >> offsetof() itself is defined by C standard to be present both in >> freestanding and hosted environment (and be available by stddef.h). > > You learn something every day! interesting (but still scary).. Quite a lot of standard headers are required to be present in freestanding environments: float.h, iso646.h, limits.h, stdarg.g, stdbool.h, stddef.h and stdint.h. Of course, these aren't required to have their usual extensions and pollution (e.g., POSIX limits in limits.h), but just things like INT_MAX which don't depend on the library. offsetof() isn't usable in sys/queue.h, but sys/queue.h already uses the equivalent __offsetof() for similar purposes. Bruce From owner-freebsd-arch@FreeBSD.ORG Wed May 9 10:08:49 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A56116A403; Wed, 9 May 2007 10:08:49 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id F1D7113C448; Wed, 9 May 2007 10:08:48 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id CFE4D10D38D; Wed, 9 May 2007 20:08:33 +1000 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id D529B8C20; Wed, 9 May 2007 20:08:39 +1000 (EST) Date: Wed, 9 May 2007 20:08:39 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andrey Chernov In-Reply-To: <20070508222521.GA59534@nagual.pp.ru> Message-ID: <20070509200000.B56490@besplex.bde.org> References: <20070502230413.Y30614@thor.farley.org> <20070503160351.GA15008@nagual.pp.ru> <20070504085905.J39482@thor.farley.org> <20070504213312.GA33163@nagual.pp.ru> <20070504174657.D1343@thor.farley.org> <20070505213202.GA49925@nagual.pp.ru> <20070505163707.J6670@thor.farley.org> <20070505221125.GA50439@nagual.pp.ru> <20070506091835.A43775@besplex.bde.org> <20070508162458.G6015@baba.farley.org> <20070508222521.GA59534@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eischen , arch@FreeBSD.org, "Sean C. Farley" Subject: Re: HEADS DOWN 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, 09 May 2007 10:08:49 -0000 On Wed, 9 May 2007, Andrey Chernov wrote: > On Tue, May 08, 2007 at 04:37:03PM -0500, Sean C. Farley wrote: >> Would it be preferred to go ahead to use strlen() in preparation for a >> faster strlen() in the future? > ... > we can use strlen() in preparation for the future. Yes, it is better to use library functions if they do (almost) exactly what is wanted. >> I would still use the inline'd version >> when counting characters while watching for an '=' character. Or should >> it also be changed to perform a strlen() and then a strchr()? > > Combined strlen()+strchr() will be slower in any case than single loop, so > better leave it as is. The compiler could in theory reduce to a single loop, but I've never seen one that does and would use the loop myself. Bruce From owner-freebsd-arch@FreeBSD.ORG Thu May 10 23:35:46 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DDE1C16A400; Thu, 10 May 2007 23:35:46 +0000 (UTC) (envelope-from bushman@freebsd.org) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.freebsd.org (Postfix) with ESMTP id CF20A13C45A; Thu, 10 May 2007 23:35:45 +0000 (UTC) (envelope-from bushman@freebsd.org) Received: from [83.188.106.197] (m83-188-106-197.cust.tele2.ru [83.188.106.197]) (authenticated bits=0) by mail.r61.net (8.14.1/8.14.1) with ESMTP id l4AN3mv7031228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 May 2007 03:03:55 +0400 (MSD) (envelope-from bushman@freebsd.org) Message-ID: <4643A4CB.4070801@freebsd.org> Date: Fri, 11 May 2007 03:03:39 +0400 From: Michael Bushkov User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: Brooks Davis , freebsd-arch@freebsd.org Subject: [PATCH] getipnodebyXXX() via gethostbyXXX() patch 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: Thu, 10 May 2007 23:35:47 -0000 Hi, During my Summer Of Code 2006 work I've done a lot of refactoring in libc's nsswitch, which was basically needed to separate libc and nsswitch modules. One part of that refactoring was reimplementation of getipnodebyXXX() family of functions through gethostbyXXX() family of functions. Actually both of these groups of functions had a lot of duplicated (or very similar) code, so such reimplementation seems to be quite logic to me. The patch is here: http://rsu.ru/~bushman/name6.patch It would be great to have it tested (maybe with nsswitch regression tests - /tools/regresion/lib/libc/nss) and to hear comments about it. -- With best regards, Michael Bushkov Southern Federal University From owner-freebsd-arch@FreeBSD.ORG Thu May 10 23:57:54 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3CA7016A400; Thu, 10 May 2007 23:57:54 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id CFDC813C43E; Thu, 10 May 2007 23:57:53 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from [192.168.1.211] ([192.168.1.211]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l4ANxGLI049852; Thu, 10 May 2007 18:59:23 -0500 (CDT) (envelope-from sean-freebsd@farley.org) Date: Thu, 10 May 2007 18:58:45 -0500 (CDT) From: "Sean C. Farley" To: Bruce Evans In-Reply-To: <20070509200000.B56490@besplex.bde.org> Message-ID: <20070510184447.H4969@baba.farley.org> References: <20070502230413.Y30614@thor.farley.org> <20070503160351.GA15008@nagual.pp.ru> <20070504085905.J39482@thor.farley.org> <20070504213312.GA33163@nagual.pp.ru> <20070504174657.D1343@thor.farley.org> <20070505213202.GA49925@nagual.pp.ru> <20070505163707.J6670@thor.farley.org> <20070505221125.GA50439@nagual.pp.ru> <20070506091835.A43775@besplex.bde.org> <20070508162458.G6015@baba.farley.org> <20070508222521.GA59534@nagual.pp.ru> <20070509200000.B56490@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eischen , arch@FreeBSD.org, Andrey Chernov Subject: Re: HEADS DOWN 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: Thu, 10 May 2007 23:57:54 -0000 On Wed, 9 May 2007, Bruce Evans wrote: > On Wed, 9 May 2007, Andrey Chernov wrote: > >> On Tue, May 08, 2007 at 04:37:03PM -0500, Sean C. Farley wrote: >>> Would it be preferred to go ahead to use strlen() in preparation >>> for a faster strlen() in the future? >> ... >> we can use strlen() in preparation for the future. > > Yes, it is better to use library functions if they do (almost) exactly > what is wanted. > >>> I would still use the inline'd version when counting characters >>> while watching for an '=' character. Or should it also be changed >>> to perform a strlen() and then a strchr()? >> >> Combined strlen()+strchr() will be slower in any case than single >> loop, so better leave it as is. > > The compiler could in theory reduce to a single loop, but I've never > seen one that does and would use the loop myself. I changed the code[1] to use strlen() and strncmp() instead of some of my hand-built functions while keeping the strlen() + '=' function. Would there be any other changes anybody can see need to be made? What type of testing would be desired? The regression tests I wrote provide a good basic test. In an attempt to make strlen() faster, I wrote a new strlen()[2] that performs a trick to boost performance by searching by word then by byte within a word to find the NUL byte. It did not compare to the speed of the built-in strlen() in GCC, but it is twice as fast as lib/libc/string/strlen.c. It was hard to really compare due to the built-in code as well as what __pure does. __pure seemed to make all versions the same speed. At some times, I really did not know for certain which version (assembly, builtin, original, new) of strlen() I was testing. :) Sean 1. http://www.farley.org/freebsd/tmp/setenv-8/POSIX/sysenv-strlen.c 2. http://www.farley.org/freebsd/tmp/strlen.c -- sean-freebsd@farley.org From owner-freebsd-arch@FreeBSD.ORG Fri May 11 00:35:01 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D9D5916A402; Fri, 11 May 2007 00:35:01 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 5335413C44B; Fri, 11 May 2007 00:35:01 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l4B0Yjs0006539; Fri, 11 May 2007 04:34:45 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l4B0YiRD006538; Fri, 11 May 2007 04:34:44 +0400 (MSD) (envelope-from ache) Date: Fri, 11 May 2007 04:34:44 +0400 From: Andrey Chernov To: "Sean C. Farley" Message-ID: <20070511003443.GA6422@nagual.pp.ru> References: <20070504213312.GA33163@nagual.pp.ru> <20070504174657.D1343@thor.farley.org> <20070505213202.GA49925@nagual.pp.ru> <20070505163707.J6670@thor.farley.org> <20070505221125.GA50439@nagual.pp.ru> <20070506091835.A43775@besplex.bde.org> <20070508162458.G6015@baba.farley.org> <20070508222521.GA59534@nagual.pp.ru> <20070509200000.B56490@besplex.bde.org> <20070510184447.H4969@baba.farley.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070510184447.H4969@baba.farley.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Daniel Eischen , arch@FreeBSD.org Subject: Re: HEADS DOWN 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, 11 May 2007 00:35:01 -0000 On Thu, May 10, 2007 at 06:58:45PM -0500, Sean C. Farley wrote: > Would there be any other changes anybody can see need to be made? What > type of testing would be desired? The regression tests I wrote provide > a good basic test. I worry about this sort of things errx(EXIT_FAILURE, "environ corrupt"); There is no mention anywhere that *env() functions can exit the program. Moreover some programs in theory can temprorarily put incorrect values into environment via putenv() after-modification or direct environ assignments for their own reasons. I suggest to change errx() to warnx()+return(failure). -- http://ache.pp.ru/ From owner-freebsd-arch@FreeBSD.ORG Fri May 11 08:55:43 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F80216A404; Fri, 11 May 2007 08:55:43 +0000 (UTC) (envelope-from mux@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6D22513C45A; Fri, 11 May 2007 08:55:43 +0000 (UTC) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 530FD1A3C1A; Fri, 11 May 2007 01:35:02 -0700 (PDT) Date: Fri, 11 May 2007 10:35:02 +0200 From: Maxime Henrion To: "Sean C. Farley" Message-ID: <20070511083502.GJ54713@elvis.mu.org> References: <20070504213312.GA33163@nagual.pp.ru> <20070504174657.D1343@thor.farley.org> <20070505213202.GA49925@nagual.pp.ru> <20070505163707.J6670@thor.farley.org> <20070505221125.GA50439@nagual.pp.ru> <20070506091835.A43775@besplex.bde.org> <20070508162458.G6015@baba.farley.org> <20070508222521.GA59534@nagual.pp.ru> <20070509200000.B56490@besplex.bde.org> <20070510184447.H4969@baba.farley.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070510184447.H4969@baba.farley.org> User-Agent: Mutt/1.4.2.2i Cc: Daniel Eischen , arch@FreeBSD.org, Andrey Chernov Subject: Re: HEADS DOWN 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, 11 May 2007 08:55:43 -0000 Sean C. Farley wrote: > On Wed, 9 May 2007, Bruce Evans wrote: > > >On Wed, 9 May 2007, Andrey Chernov wrote: > > > >>On Tue, May 08, 2007 at 04:37:03PM -0500, Sean C. Farley wrote: > >>> Would it be preferred to go ahead to use strlen() in preparation > >>> for a faster strlen() in the future? > >>... > >>we can use strlen() in preparation for the future. > > > >Yes, it is better to use library functions if they do (almost) exactly > >what is wanted. > > > >>> I would still use the inline'd version when counting characters > >>> while watching for an '=' character. Or should it also be changed > >>> to perform a strlen() and then a strchr()? > >> > >>Combined strlen()+strchr() will be slower in any case than single > >>loop, so better leave it as is. > > > >The compiler could in theory reduce to a single loop, but I've never > >seen one that does and would use the loop myself. > > I changed the code[1] to use strlen() and strncmp() instead of some of > my hand-built functions while keeping the strlen() + '=' function. > Would there be any other changes anybody can see need to be made? What > type of testing would be desired? The regression tests I wrote provide > a good basic test. > > In an attempt to make strlen() faster, I wrote a new strlen()[2] that > performs a trick to boost performance by searching by word then by byte > within a word to find the NUL byte. It did not compare to the speed of > the built-in strlen() in GCC, but it is twice as fast as > lib/libc/string/strlen.c. It was hard to really compare due to the > built-in code as well as what __pure does. __pure seemed to make all > versions the same speed. At some times, I really did not know for > certain which version (assembly, builtin, original, new) of strlen() I > was testing. :) Just for the record, __attribute__((pure)) tells GCC that the function's return value solely depends on the parameters passed in (and possibly global memory). That is, if you call such a function several times providing the same parameters for each call, and if it is clear that no global memory can have changed in between, then you are guaranteed to get back the same result, and the compiler can safely get rid of some calls and enable some more optimizations. There is also __attribute__((const)) which basically is like pure except that the function isn't allowed to read global memory, and thus even more calls can be removed. I think we export this one as __pure2 in FreeBSD. Note that strlen() isn't 'const' because it's passed char pointers so you could call it two times passing the same pointers, but the memory they are pointing to may have changed in between. So strlen() is only 'pure'. For the interested reader, your functions always have these properties in a pure functional programming language, which allows the compiler to do some really neat tricks such as caching the result of functions to avoid evaluating them again (memoization). Cheers, Maxime From owner-freebsd-arch@FreeBSD.ORG Fri May 11 23:20:16 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 993DB16A406 for ; Fri, 11 May 2007 23:20:16 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 3EDCF13C483 for ; Fri, 11 May 2007 23:20:16 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from [192.168.1.211] ([192.168.1.211]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l4BNK8DR071926; Fri, 11 May 2007 18:20:13 -0500 (CDT) (envelope-from sean-freebsd@farley.org) Date: Fri, 11 May 2007 18:21:09 -0500 (CDT) From: "Sean C. Farley" To: Maxime Henrion In-Reply-To: <20070511083502.GJ54713@elvis.mu.org> Message-ID: <20070511181141.P9004@baba.farley.org> References: <20070504213312.GA33163@nagual.pp.ru> <20070504174657.D1343@thor.farley.org> <20070505213202.GA49925@nagual.pp.ru> <20070505163707.J6670@thor.farley.org> <20070505221125.GA50439@nagual.pp.ru> <20070506091835.A43775@besplex.bde.org> <20070508162458.G6015@baba.farley.org> <20070508222521.GA59534@nagual.pp.ru> <20070509200000.B56490@besplex.bde.org> <20070510184447.H4969@baba.farley.org> <20070511083502.GJ54713@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: HEADS DOWN 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, 11 May 2007 23:20:16 -0000 On Fri, 11 May 2007, Maxime Henrion wrote: > Sean C. Farley wrote: >> In an attempt to make strlen() faster, I wrote a new strlen()[2] that >> performs a trick to boost performance by searching by word then by >> byte within a word to find the NUL byte. It did not compare to the >> speed of the built-in strlen() in GCC, but it is twice as fast as >> lib/libc/string/strlen.c. It was hard to really compare due to the >> built-in code as well as what __pure does. __pure seemed to make all >> versions the same speed. At some times, I really did not know for >> certain which version (assembly, builtin, original, new) of strlen() >> I was testing. :) > > Just for the record, __attribute__((pure)) tells GCC that the > function's return value solely depends on the parameters passed in > (and possibly global memory). That is, if you call such a function > several times providing the same parameters for each call, and if it > is clear that no global memory can have changed in between, then you > are guaranteed to get back the same result, and the compiler can > safely get rid of some calls and enable some more optimizations. > > There is also __attribute__((const)) which basically is like pure > except that the function isn't allowed to read global memory, and thus > even more calls can be removed. I think we export this one as __pure2 > in FreeBSD. > > Note that strlen() isn't 'const' because it's passed char pointers so > you could call it two times passing the same pointers, but the memory > they are pointing to may have changed in between. So strlen() is only > 'pure'. > > For the interested reader, your functions always have these properties > in a pure functional programming language, which allows the compiler > to do some really neat tricks such as caching the result of functions > to avoid evaluating them again (memoization). That is interesting. Compiler optimizations sure have changed a lot while I was not looking. Please correct me if I am wrong: programs compiled by GCC on FreeBSD use the builtin strlen() unless told not. If builtin strlen() is disabled, i386 will use the assembly version while all other platforms use the C version. Regardless of the version, __pure is taken into account. It seems that __attribute__((pure)) is not supported by the Intel compiler. Would my strlen() be of any use when libc is compiled with it? Sean -- sean-freebsd@farley.org From owner-freebsd-arch@FreeBSD.ORG Fri May 11 23:43:46 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B7EA916A403; Fri, 11 May 2007 23:43:46 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 7CC7B13C458; Fri, 11 May 2007 23:43:46 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from [192.168.1.211] ([192.168.1.211]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l4BNhZSO072236; Fri, 11 May 2007 18:43:40 -0500 (CDT) (envelope-from sean-freebsd@farley.org) Date: Fri, 11 May 2007 18:44:37 -0500 (CDT) From: "Sean C. Farley" To: Andrey Chernov In-Reply-To: <20070511003443.GA6422@nagual.pp.ru> Message-ID: <20070511182126.U9004@baba.farley.org> References: <20070504213312.GA33163@nagual.pp.ru> <20070504174657.D1343@thor.farley.org> <20070505213202.GA49925@nagual.pp.ru> <20070505163707.J6670@thor.farley.org> <20070505221125.GA50439@nagual.pp.ru> <20070506091835.A43775@besplex.bde.org> <20070508162458.G6015@baba.farley.org> <20070508222521.GA59534@nagual.pp.ru> <20070509200000.B56490@besplex.bde.org> <20070510184447.H4969@baba.farley.org> <20070511003443.GA6422@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eischen , arch@FreeBSD.org Subject: Re: HEADS DOWN 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, 11 May 2007 23:43:46 -0000 On Fri, 11 May 2007, Andrey Chernov wrote: > On Thu, May 10, 2007 at 06:58:45PM -0500, Sean C. Farley wrote: >> Would there be any other changes anybody can see need to be made? What >> type of testing would be desired? The regression tests I wrote provide >> a good basic test. > > I worry about this sort of things > errx(EXIT_FAILURE, "environ corrupt"); > > There is no mention anywhere that *env() functions can exit the > program. Moreover some programs in theory can temprorarily put > incorrect values into environment via putenv() after-modification or > direct environ assignments for their own reasons. > > I suggest to change errx() to warnx()+return(failure). No need to worry any longer; I changed them into warnx(). What value should I give errno? I do not want the program to receive a random error code. The first warnx() could be EINVAL. The second warnx() would be a coding error on my part. EDOOFUS would fit. :) I know I should not use it. EINVAL? Sean -- sean-freebsd@farley.org From owner-freebsd-arch@FreeBSD.ORG Sat May 12 15:10:45 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C7F116A402; Sat, 12 May 2007 15:10:45 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id E212F13C45D; Sat, 12 May 2007 15:10:44 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 7BAE146F6D; Sat, 12 May 2007 11:10:44 -0400 (EDT) Date: Sat, 12 May 2007 16:10:44 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Sean C. Farley" In-Reply-To: <20070511182126.U9004@baba.farley.org> Message-ID: <20070512160859.T63806@fledge.watson.org> References: <20070504213312.GA33163@nagual.pp.ru> <20070504174657.D1343@thor.farley.org> <20070505213202.GA49925@nagual.pp.ru> <20070505163707.J6670@thor.farley.org> <20070505221125.GA50439@nagual.pp.ru> <20070506091835.A43775@besplex.bde.org> <20070508162458.G6015@baba.farley.org> <20070508222521.GA59534@nagual.pp.ru> <20070509200000.B56490@besplex.bde.org> <20070510184447.H4969@baba.farley.org> <20070511003443.GA6422@nagual.pp.ru> <20070511182126.U9004@baba.farley.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eischen , arch@FreeBSD.org, Andrey Chernov Subject: Re: HEADS DOWN 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, 12 May 2007 15:10:45 -0000 On Fri, 11 May 2007, Sean C. Farley wrote: > On Fri, 11 May 2007, Andrey Chernov wrote: > >> On Thu, May 10, 2007 at 06:58:45PM -0500, Sean C. Farley wrote: >>> Would there be any other changes anybody can see need to be made? What >>> type of testing would be desired? The regression tests I wrote provide >>> a good basic test. >> >> I worry about this sort of things errx(EXIT_FAILURE, "environ corrupt"); >> >> There is no mention anywhere that *env() functions can exit the program. >> Moreover some programs in theory can temprorarily put incorrect values into >> environment via putenv() after-modification or direct environ assignments >> for their own reasons. >> >> I suggest to change errx() to warnx()+return(failure). > > No need to worry any longer; I changed them into warnx(). What value should > I give errno? I do not want the program to receive a random error code. > The first warnx() could be EINVAL. The second warnx() would be a coding > error on my part. EDOOFUS would fit. :) I know I should not use it. > EINVAL? Actually, I'm not convinced that crashing the program isn't the right answer. If an application corrupts memory managed by libc or other libraries, crashing is generally considered an entirely acceptable failure mode. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Sat May 12 15:24:00 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8FD3316A403; Sat, 12 May 2007 15:24:00 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 1055513C448; Sat, 12 May 2007 15:23:59 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l4CFNmS8028911; Sat, 12 May 2007 19:23:48 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l4CFNmpQ028910; Sat, 12 May 2007 19:23:48 +0400 (MSD) (envelope-from ache) Date: Sat, 12 May 2007 19:23:48 +0400 From: Andrey Chernov To: Robert Watson Message-ID: <20070512152347.GA28834@nagual.pp.ru> References: <20070505163707.J6670@thor.farley.org> <20070505221125.GA50439@nagual.pp.ru> <20070506091835.A43775@besplex.bde.org> <20070508162458.G6015@baba.farley.org> <20070508222521.GA59534@nagual.pp.ru> <20070509200000.B56490@besplex.bde.org> <20070510184447.H4969@baba.farley.org> <20070511003443.GA6422@nagual.pp.ru> <20070511182126.U9004@baba.farley.org> <20070512160859.T63806@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070512160859.T63806@fledge.watson.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Daniel Eischen , arch@freebsd.org, "Sean C. Farley" Subject: Re: HEADS DOWN 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, 12 May 2007 15:24:00 -0000 On Sat, May 12, 2007 at 04:10:44PM +0100, Robert Watson wrote: > Actually, I'm not convinced that crashing the program isn't the right > answer. If an application corrupts memory managed by libc or other > libraries, crashing is generally considered an entirely acceptable failure > mode. It can be corruption, yes, but it can be intentional action too. Many programs directly perform environ clearing or modifications. In case it will be directly allowed to put anything there, I would insist of removing not errx() but even warnx(), but situation is unclear. POSIX forbids modifying environ directly, but C99 have getenv() only and allows direct modification of environ, so what happens depends on standard and common practice. -- http://ache.pp.ru/ From owner-freebsd-arch@FreeBSD.ORG Sat May 12 15:27:48 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2DCB116A400; Sat, 12 May 2007 15:27:48 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id A3F0713C448; Sat, 12 May 2007 15:27:47 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l4CFRbu3028965; Sat, 12 May 2007 19:27:37 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l4CFRZKg028964; Sat, 12 May 2007 19:27:35 +0400 (MSD) (envelope-from ache) Date: Sat, 12 May 2007 19:27:35 +0400 From: Andrey Chernov To: "Sean C. Farley" Message-ID: <20070512152735.GB28834@nagual.pp.ru> References: <20070505213202.GA49925@nagual.pp.ru> <20070505163707.J6670@thor.farley.org> <20070505221125.GA50439@nagual.pp.ru> <20070506091835.A43775@besplex.bde.org> <20070508162458.G6015@baba.farley.org> <20070508222521.GA59534@nagual.pp.ru> <20070509200000.B56490@besplex.bde.org> <20070510184447.H4969@baba.farley.org> <20070511003443.GA6422@nagual.pp.ru> <20070511182126.U9004@baba.farley.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070511182126.U9004@baba.farley.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Daniel Eischen , arch@FreeBSD.org Subject: Re: HEADS DOWN 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, 12 May 2007 15:27:48 -0000 On Fri, May 11, 2007 at 06:44:37PM -0500, Sean C. Farley wrote: > No need to worry any longer; I changed them into warnx(). What value > should I give errno? I do not want the program to receive a random > error code. The first warnx() could be EINVAL. The second warnx() > would be a coding error on my part. EDOOFUS would fit. :) I know I > should not use it. EINVAL? IMHO EFAULT. EDOOFUS is not POSIX-allowed errno. EINVAL used primarily for arg checking. -- http://ache.pp.ru/ From owner-freebsd-arch@FreeBSD.ORG Sat May 12 15:31:50 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 668D016A406; Sat, 12 May 2007 15:31:50 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 1BFE313C469; Sat, 12 May 2007 15:31:50 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54a5ff71.dip.t-dialin.net [84.165.255.113]) by redbull.bpaserver.net (Postfix) with ESMTP id CFE512E1D3; Sat, 12 May 2007 17:08:04 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id C09A45B48A3; Sat, 12 May 2007 17:07:48 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l4CF7mmu011089; Sat, 12 May 2007 17:07:48 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from proxy.Leidinger.net (proxy.Leidinger.net [192.168.1.103]) by webmail.leidinger.net (Horde MIME library) with HTTP; Sat, 12 May 2007 17:07:48 +0200 Message-ID: <20070512170748.msq4hriby804skcg@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Sat, 12 May 2007 17:07:48 +0200 From: Alexander Leidinger To: "Sean C. Farley" References: <20070504213312.GA33163@nagual.pp.ru> <20070504174657.D1343@thor.farley.org> <20070505213202.GA49925@nagual.pp.ru> <20070505163707.J6670@thor.farley.org> <20070505221125.GA50439@nagual.pp.ru> <20070506091835.A43775@besplex.bde.org> <20070508162458.G6015@baba.farley.org> <20070508222521.GA59534@nagual.pp.ru> <20070509200000.B56490@besplex.bde.org> <20070510184447.H4969@baba.farley.org> <20070511083502.GJ54713@elvis.mu.org> <20070511181141.P9004@baba.farley.org> In-Reply-To: <20070511181141.P9004@baba.farley.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.864, required 8, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: arch@freebsd.org Subject: Re: HEADS DOWN 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, 12 May 2007 15:31:50 -0000 Quoting "Sean C. Farley" (from Fri, 11 May 2007 18:21:09 -0500 (CDT)): > It seems that __attribute__((pure)) is not supported by the Intel > compiler. Would my strlen() be of any use when libc is compiled with > it? That's one reason we have cdefs.h, so you can use appropriate macros instead of using __attribute__((foo)) directly. Bye, Alexander. -- BOFH excuse #168: le0: no carrier: transceiver cable problem? http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Sat May 12 16:02:22 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5A2D16A400; Sat, 12 May 2007 16:02:22 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 935EF13C458; Sat, 12 May 2007 16:02:22 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 25A931A3C1A; Sat, 12 May 2007 08:35:32 -0700 (PDT) Date: Sat, 12 May 2007 08:35:32 -0700 From: Alfred Perlstein To: Robert Watson Message-ID: <20070512153532.GQ21795@elvis.mu.org> References: <20070505163707.J6670@thor.farley.org> <20070505221125.GA50439@nagual.pp.ru> <20070506091835.A43775@besplex.bde.org> <20070508162458.G6015@baba.farley.org> <20070508222521.GA59534@nagual.pp.ru> <20070509200000.B56490@besplex.bde.org> <20070510184447.H4969@baba.farley.org> <20070511003443.GA6422@nagual.pp.ru> <20070511182126.U9004@baba.farley.org> <20070512160859.T63806@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070512160859.T63806@fledge.watson.org> User-Agent: Mutt/1.4.2.2i Cc: Daniel Eischen , arch@FreeBSD.org, Andrey Chernov , "Sean C. Farley" Subject: Re: HEADS DOWN 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, 12 May 2007 16:02:22 -0000 * Robert Watson [070512 08:11] wrote: > > > Actually, I'm not convinced that crashing the program isn't the right > answer. If an application corrupts memory managed by libc or other > libraries, crashing is generally considered an entirely acceptable failure > mode. Phk malloc has said otherwise for the past ... 10 years? I like how phk malloc has it as an option. -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Sat May 12 17:55:55 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 149AD16A404; Sat, 12 May 2007 17:55:55 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A5FAE13C4C1; Sat, 12 May 2007 17:55:54 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 1180617383; Sat, 12 May 2007 17:55:53 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l4CHttti063985; Sat, 12 May 2007 17:55:56 GMT (envelope-from phk@critter.freebsd.dk) To: Alfred Perlstein From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 12 May 2007 08:35:32 MST." <20070512153532.GQ21795@elvis.mu.org> Date: Sat, 12 May 2007 17:55:55 +0000 Message-ID: <63984.1178992555@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Daniel Eischen , arch@freebsd.org, Robert Watson , "Sean C. Farley" Subject: Re: HEADS DOWN 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, 12 May 2007 17:55:55 -0000 In message <20070512153532.GQ21795@elvis.mu.org>, Alfred Perlstein writes: >* Robert Watson [070512 08:11] wrote: >> >> >> Actually, I'm not convinced that crashing the program isn't the right >> answer. If an application corrupts memory managed by libc or other >> libraries, crashing is generally considered an entirely acceptable failure >> mode. > >Phk malloc has said otherwise for the past ... 10 years? > >I like how phk malloc has it as an option. But notice that it is not an option for programs that runs as root or setuid/setgid etc. Given the hostility of networks, I would support a more hardcore attitude to memory mismanagement these days. -- 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 May 12 22:07:13 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D497316A406 for ; Sat, 12 May 2007 22:07:13 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 9C7C313C458 for ; Sat, 12 May 2007 22:07:13 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l4CM7AIJ005241; Sat, 12 May 2007 17:07:10 -0500 (CDT) (envelope-from sean-freebsd@farley.org) Date: Sat, 12 May 2007 17:07:09 -0500 (CDT) From: "Sean C. Farley" To: Alexander Leidinger In-Reply-To: <20070512170748.msq4hriby804skcg@webmail.leidinger.net> Message-ID: <20070512170535.A7595@thor.farley.org> References: <20070504213312.GA33163@nagual.pp.ru> <20070504174657.D1343@thor.farley.org> <20070505213202.GA49925@nagual.pp.ru> <20070505163707.J6670@thor.farley.org> <20070505221125.GA50439@nagual.pp.ru> <20070506091835.A43775@besplex.bde.org> <20070508162458.G6015@baba.farley.org> <20070508222521.GA59534@nagual.pp.ru> <20070509200000.B56490@besplex.bde.org> <20070510184447.H4969@baba.farley.org> <20070511083502.GJ54713@elvis.mu.org> <20070511181141.P9004@baba.farley.org> <20070512170748.msq4hriby804skcg@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: HEADS DOWN 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, 12 May 2007 22:07:13 -0000 On Sat, 12 May 2007, Alexander Leidinger wrote: > Quoting "Sean C. Farley" (from Fri, 11 May 2007 > 18:21:09 -0500 (CDT)): > >> It seems that __attribute__((pure)) is not supported by the Intel >> compiler. Would my strlen() be of any use when libc is compiled with >> it? > > That's one reason we have cdefs.h, so you can use appropriate macros > instead of using __attribute__((foo)) directly. Actually, what I meant was that strlen() has the pure attribute via __pure, and cdefs.h shows that the Intel compiler is not able to make use of it. Sean -- sean-freebsd@farley.org From owner-freebsd-arch@FreeBSD.ORG Sat May 12 22:25:10 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F03416A407; Sat, 12 May 2007 22:25:10 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 0C5FA13C48A; Sat, 12 May 2007 22:25:09 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l4CMP3GV005745; Sat, 12 May 2007 17:25:03 -0500 (CDT) (envelope-from sean-freebsd@farley.org) Date: Sat, 12 May 2007 17:25:03 -0500 (CDT) From: "Sean C. Farley" To: Robert Watson In-Reply-To: <20070512160859.T63806@fledge.watson.org> Message-ID: <20070512170737.F7595@thor.farley.org> References: <20070504213312.GA33163@nagual.pp.ru> <20070504174657.D1343@thor.farley.org> <20070505213202.GA49925@nagual.pp.ru> <20070505163707.J6670@thor.farley.org> <20070505221125.GA50439@nagual.pp.ru> <20070506091835.A43775@besplex.bde.org> <20070508162458.G6015@baba.farley.org> <20070508222521.GA59534@nagual.pp.ru> <20070509200000.B56490@besplex.bde.org> <20070510184447.H4969@baba.farley.org> <20070511003443.GA6422@nagual.pp.ru> <20070511182126.U9004@baba.farley.org> <20070512160859.T63806@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eischen , arch@FreeBSD.org, Andrey Chernov Subject: Re: HEADS DOWN 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, 12 May 2007 22:25:10 -0000 On Sat, 12 May 2007, Robert Watson wrote: > On Fri, 11 May 2007, Sean C. Farley wrote: > >> On Fri, 11 May 2007, Andrey Chernov wrote: >>> I suggest to change errx() to warnx()+return(failure). >> >> No need to worry any longer; I changed them into warnx(). What value >> should I give errno? I do not want the program to receive a random >> error code. The first warnx() could be EINVAL. The second warnx() >> would be a coding error on my part. EDOOFUS would fit. :) I know I >> should not use it. EINVAL? > > Actually, I'm not convinced that crashing the program isn't the right > answer. If an application corrupts memory managed by libc or other > libraries, crashing is generally considered an entirely acceptable > failure mode. There are two scenarios when rebuilding the environment for the first time that I am using warnx/errx: 1. The user supplied an environ where a variable is missing an "=value" portion. 2. The code I wrote did not work as expected. Is your thought that since the API has no means (specification-wise) to inform the user that something is wrong that an exit should/may be performed? To stick with the specification, I see why errx() would be desired. In addition, malloc() can handle a double-free and still run correctly. For environ, if it is incorrect, the code will never allow *env() to succeed. Sean -- sean-freebsd@farley.org