From owner-freebsd-arch@FreeBSD.ORG Sun Jun 13 00:49:39 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29B1916A4D0 for ; Sun, 13 Jun 2004 00:49:39 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFD2B43D1F for ; Sun, 13 Jun 2004 00:49:38 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 12637 invoked from network); 13 Jun 2004 00:49:19 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 13 Jun 2004 00:49:19 -0000 Received: from hydrogen.funkthat.com (jsbapq@localhost.funkthat.com [127.0.0.1])i5D0nJHX035705; Sat, 12 Jun 2004 17:49:19 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i5D0nH5I035704; Sat, 12 Jun 2004 17:49:17 -0700 (PDT) Date: Sat, 12 Jun 2004 17:49:17 -0700 From: John-Mark Gurney To: Robert Watson Message-ID: <20040613004917.GC542@funkthat.com> Mail-Followup-To: Robert Watson , Poul-Henning Kamp , arch@freebsd.org, Julian Elischer References: <57800.1086807537@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: arch@freebsd.org cc: Poul-Henning Kamp cc: Julian Elischer Subject: Re: reference counting.. continued.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2004 00:49:39 -0000 Robert Watson wrote this message on Sat, Jun 12, 2004 at 15:33 -0400: > > Our reference counts will almost invariably be integral properties of > > our objects and therefore has to interact with the remaining object > > locking. > > I don't have a strong feeling about the general need for a refcount API, > but I can confirm that many of the interesting objects in the kernel > wouldn't lend themselves to such an API. There are many cases where we'll > want to protect the reference count using an existing lock, in which case > locking built into the reference count API becomes a liability. Socket > reference counting is one example of this: in some ways, it's a general > purpose reference count, but the GC behavior is specific to sockets and > depends on additional uncounted references from file descriptors and the > prototocol layer. In working on locking down KQ, I came across the same problem. What I ended up doing is creating an object that kept a copy of struct mtx * in it. When I created the object, you could either pass in a NULL, and a fresh mutex would be created, or you could pass in your own object's struct mtx *... This makes it more capable of flexibility and only requires a lock/unlocked arg... Just a thought... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Sun Jun 13 01:00:01 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F24D16A4CE; Sun, 13 Jun 2004 01:00:01 +0000 (GMT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E74843D46; Sun, 13 Jun 2004 01:00:00 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc12) with ESMTP id <20040613005925012002eh9se>; Sun, 13 Jun 2004 00:59:26 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA07421; Sat, 12 Jun 2004 17:59:25 -0700 (PDT) Date: Sat, 12 Jun 2004 17:59:23 -0700 (PDT) From: Julian Elischer To: Robert Watson In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: Poul-Henning Kamp Subject: Re: reference counting.. continued.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2004 01:00:01 -0000 On Sat, 12 Jun 2004, Robert Watson wrote: > > On Wed, 9 Jun 2004, Poul-Henning Kamp wrote: > > > I am not in favour of a dedicated API for refcounts. > > > > A dedicated API works if the refcount is a detached property of the > > object, and that is not normally the case outside OO+GC implementations. > > > > Our reference counts will almost invariably be integral properties of > > our objects and therefore has to interact with the remaining object > > locking. > > I don't have a strong feeling about the general need for a refcount API, > but I can confirm that many of the interesting objects in the kernel > wouldn't lend themselves to such an API. There are many cases where we'll > want to protect the reference count using an existing lock, in which case > locking built into the reference count API becomes a liability. Socket > reference counting is one example of this: in some ways, it's a general > purpose reference count, but the GC behavior is specific to sockets and > depends on additional uncounted references from file descriptors and the > prototocol layer. That's the problem... "uncounted references". Either you are counting references or you are not.. > > That said, I think making sure people get reference counts right is > important: at the very least, I think it would be useful to have a > refcount(9) man page with a well thought out example of a simple reference > count implementation, or a pointer at such an implementation (ucred isn't > bad). > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Senior Research Scientist, McAfee Research > > > From owner-freebsd-arch@FreeBSD.ORG Sun Jun 13 04:12:24 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 409A216A4D2 for ; Sun, 13 Jun 2004 04:12:21 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 512C543D1F for ; Sun, 13 Jun 2004 04:12:20 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from freebsd.org (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i5D4EXrF000393; Sat, 12 Jun 2004 22:14:34 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <40CBD3F3.7040407@freebsd.org> Date: Sat, 12 Jun 2004 22:11:31 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Polstra References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-arch@freebsd.org Subject: Re: RFC: API change for sema_timedwait X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2004 04:12:24 -0000 John Polstra wrote: > Before 5.x becomes -stable, I'd like to change the API of > sema_timedwait(9). This function is used in only 3 places in the > kernel, all in "dev/ips/ips_commands.c". > > Currently, sema_timedwait returns 0 if the operation fails due to a > timeout. On success, it returns a non-zero value. This is precisely > the opposite of the standard convention in the kernel, where 0 means > success and a non-zero value (taken from ) means failure. > The convention exists because most functions can succeed in only one > way but can fail in several different ways. > > The reason I care about this is because I'd like to add new functions > sema_wait_sig() and sema_timedwait_sig() which can be interrupted > by a signal. Then sema_timedwait_sig could fail in two different > ways: as a result of a timeout or as a result of a signal. If these > functions returned proper errno values on failure, it would be easy to > distinguish between the two failure cases. > > This change would also make the return values of sema_timedwait, > sema_wait_sig, and sema_timedwait_sig consistent with the analogous > condition variable operations cv_timedwait, cv_wait_sig, and > cv_timedwait_sig and with tsleep and msleep. > > Does this change sound OK to you folks? > > John Being the ips maintainer, I have no objection to this change. Scott From owner-freebsd-arch@FreeBSD.ORG Mon Jun 14 17:23:50 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31AC216A4CE for ; Mon, 14 Jun 2004 17:23:50 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id D267E43D6B for ; Mon, 14 Jun 2004 17:23:49 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 18948 invoked from network); 14 Jun 2004 17:20:50 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 14 Jun 2004 17:20:50 -0000 Received: from 10.50.41.233 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i5EHKkhG057506; Mon, 14 Jun 2004 13:20:47 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Mon, 14 Jun 2004 13:21:42 -0400 User-Agent: KMail/1.6 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406141321.42275.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: John Polstra Subject: Re: RFC: API change for sema_timedwait X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2004 17:23:50 -0000 On Saturday 12 June 2004 03:15 pm, John Polstra wrote: > Before 5.x becomes -stable, I'd like to change the API of > sema_timedwait(9). This function is used in only 3 places in the > kernel, all in "dev/ips/ips_commands.c". > > Currently, sema_timedwait returns 0 if the operation fails due to a > timeout. On success, it returns a non-zero value. This is precisely > the opposite of the standard convention in the kernel, where 0 means > success and a non-zero value (taken from ) means failure. > The convention exists because most functions can succeed in only one > way but can fail in several different ways. > > The reason I care about this is because I'd like to add new functions > sema_wait_sig() and sema_timedwait_sig() which can be interrupted > by a signal. Then sema_timedwait_sig could fail in two different > ways: as a result of a timeout or as a result of a signal. If these > functions returned proper errno values on failure, it would be easy to > distinguish between the two failure cases. > > This change would also make the return values of sema_timedwait, > sema_wait_sig, and sema_timedwait_sig consistent with the analogous > condition variable operations cv_timedwait, cv_wait_sig, and > cv_timedwait_sig and with tsleep and msleep. > > Does this change sound OK to you folks? Sounds ok to me. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Tue Jun 15 17:31:15 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CCAB16A4CE for ; Tue, 15 Jun 2004 17:31:15 +0000 (GMT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id D1D2843D60 for ; Tue, 15 Jun 2004 17:31:14 +0000 (GMT) (envelope-from nate@root.org) Received: (qmail 27833 invoked by uid 1000); 15 Jun 2004 17:30:44 -0000 Date: Tue, 15 Jun 2004 10:30:44 -0700 (PDT) From: Nate Lawson To: arch@freebsd.org, acpi@freebsd.org Message-ID: <20040615102506.F27810@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: ACPI mpsafe patch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2004 17:31:15 -0000 I've gone through this carefully and have tested it a lot and it appears ready for mainstream testing. I'm especially interested in SMP testing, with and without WITNESS. Run the following script on your system to test it (start 2 or 3 of these): #!/bin/sh sysctl hw.acpi.thermal.polling_rate=1 sysctl hw.acpi.battery.info_expire=1 while [ 1 ]; do apm sysctl hw.acpi done While that's going, use the system normally, suspend/resume, etc. The few parts that aren't done are acpi_video, acpi_asus, and acpi_toshiba. Once I finish these and a couple nits, I'll provide a final patch for testing as well as fix any problems found. http://www.root.org/~nate/freebsd/acpi_mpsafe.diff.gz Thanks, -Nate From owner-freebsd-arch@FreeBSD.ORG Tue Jun 15 17:16:11 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7441E16A4CE for ; Tue, 15 Jun 2004 17:16:11 +0000 (GMT) Received: from smtp.wp.pl (smtp.wp.pl [212.77.101.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CAE243D68 for ; Tue, 15 Jun 2004 17:16:10 +0000 (GMT) (envelope-from imok@wp.pl) Received: (wp-smtpd smtp.wp.pl 12891 invoked from network); 15 Jun 2004 19:16:03 +0200 Received: from dial-565.lubin.dialog.net.pl (HELO w5s0z2) (imok@[217.30.140.53]) (envelope-sender ) by smtp.wp.pl (wp-smtpd) with SMTP for ; 15 Jun 2004 19:16:03 +0200 Message-ID: <000801c452fd$84584f40$4262fea9@w5s0z2> From: "PaTaNa" To: Date: Tue, 15 Jun 2004 19:23:22 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-AntiVirus: skaner antywirusowy poczty Wirtualnej Polski S. A. [wersja 2.0c] X-WP-AntySpam-Rezultat: NIE-SPAM X-Mailman-Approved-At: Wed, 16 Jun 2004 11:47:19 +0000 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: K7VM2-R3.0 and duron 1.3Gh procesor X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2004 17:16:11 -0000 which FreeBSD is best for K7VM2-R3.0 and duron 1.3 Gh processor please = tell me that it will work mswinows really suck and I want to change From owner-freebsd-arch@FreeBSD.ORG Fri Jun 18 00:42:16 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BA0516A4CE for ; Fri, 18 Jun 2004 00:42:16 +0000 (GMT) Received: from freebsd3.cimlogic.com.au (adsl-20-121.swiftdsl.com.au [218.214.20.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F8D943D1D for ; Fri, 18 Jun 2004 00:42:15 +0000 (GMT) (envelope-from jb@cimlogic.com.au) Received: by freebsd3.cimlogic.com.au (Postfix, from userid 102) id 451166AA57; Fri, 18 Jun 2004 10:41:59 +1000 (EST) Date: Fri, 18 Jun 2004 10:41:59 +1000 From: John Birrell To: arch@freebsd.org Message-ID: <20040618004158.GN15577@freebsd3.cimlogic.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: mmap address allocation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2004 00:42:16 -0000 The current Wine code won't run on either FreeBSD4 or -current now that they've added code that tries to snaffle (mmap) all memory in user space from 0x80000000 up. They do this because Windows 9x uses that area as a shared heap. The snaffle takes place as early as they can, before they start loading libraries like ntdll and kernel32. The FreeBSD mmap address allocation in the case where no address hint is provided, always tries to allocate memory above all existing allocations. Obviously this fails when dlopen() tries to load another shared library. There is a comment in sys/vm/vm_mmap.c:mmap that mentions "There should really be a pmap call to determine a reasonable location". What are people's thoughts about implementing such a thing (and having it do a better job of choosing an address)? -- John Birrell From owner-freebsd-arch@FreeBSD.ORG Sat Jun 19 09:58:38 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC78716A535 for ; Sat, 19 Jun 2004 09:58:38 +0000 (GMT) Received: from mail.tiscali.cz (stateless2.tiscali.cz [213.235.135.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id B281743D1F for ; Sat, 19 Jun 2004 09:58:38 +0000 (GMT) (envelope-from hsn@netmag.cz) Received: from sanatana.dharma (212.90.236.212) by mail.tiscali.cz (6.7.021) id 40B1F78600B53DCB for freebsd-arch@freebsd.org; Sat, 19 Jun 2004 11:58:23 +0200 Received: from hsn@localhost by sanatana.dharma (Exim 4.33_1 FreeBSD) id 1BbcaZ-000JIF-1y for ; Sat, 19 Jun 2004 11:56:43 +0200 Date: Sat, 19 Jun 2004 11:56:43 +0200 From: Radim Kolar To: freebsd-arch@freebsd.org Message-ID: <20040619095642.GA67130@sanatana.dharma> Mail-Followup-To: freebsd-arch@freebsd.org References: <20040609154040.GA26229@asura.bsd> <20040610021356.GA4990@VARK.homeunix.com> <20040610025439.GA11655@cat.robbins.dropbear.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040610025439.GA11655@cat.robbins.dropbear.id.au> User-Agent: Mutt/1.5.6i Subject: Re: fflush() on readonly files X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2004 09:58:39 -0000 > > > 3 - Correct some programs depending on this > > Are there any such programs? Today I have stepped on another example: advancecomp (in ports): Code for returning size of file: lib/fz.c 542 /** 543 * Get the size of the file. 544 */ 545 long fzsize(adv_fz* f) 546 { 547 if (f->type == fz_file) { 548 struct stat st; 549 if (fflush(f->f) != 0) { 550 return -1; 551 } > The behavior of fflush() on a read-only stream is not defined by any > relevant standards. It is a no-op. Returning an error is not no-op. It is a failure. There are 2 cases: 1) Program knows that he has r/o fd and calls fflush() on it. > In my experience, fflush() is only called on input streams when the Microsoft > behavior is expected. 2) Program do not knows that he has r/o fd and calls fflush() as part of his normal operation. For example fflush()+fstat() pairs and fflush()+fclose() pairs. This programs expects that fflush() on r/o files do not fails. I am interested in solving case #2. I have no troubles with #1 programs; there are not a very common. > Bottom line: learn C, fix your code. There are other languages also. Major problem with this behavior lies in various Python scripts. When they calls fflush() on r/o fd, exception is thrown and aborts program. They often calls fflush before close in class which supports both r/o and r/w fd and there is no way to check type of passed descriptor. From owner-freebsd-arch@FreeBSD.ORG Sat Jun 19 10:59:44 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52FA216A4CE for ; Sat, 19 Jun 2004 10:59:44 +0000 (GMT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98CBD43D46 for ; Sat, 19 Jun 2004 10:59:43 +0000 (GMT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.11/8.12.11) with ESMTP id i5JAxedG069632 for ; Sat, 19 Jun 2004 14:59:40 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.11/8.12.11/Submit) id i5JAxdfE069631 for freebsd-arch@freebsd.org; Sat, 19 Jun 2004 14:59:39 +0400 (MSD) (envelope-from ache) Date: Sat, 19 Jun 2004 14:59:39 +0400 From: Andrey Chernov To: freebsd-arch@freebsd.org Message-ID: <20040619105938.GA69596@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , freebsd-arch@freebsd.org References: <20040609154040.GA26229@asura.bsd> <20040610021356.GA4990@VARK.homeunix.com> <20040610025439.GA11655@cat.robbins.dropbear.id.au> <20040619095642.GA67130@sanatana.dharma> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040619095642.GA67130@sanatana.dharma> User-Agent: Mutt/1.5.6i X-AntiVirus: checked by AntiVir Milter 1.1-beta; AVE 6.25.0.62; VDF 6.25.0.102 (host: pobrecita.freebsd.ru) Subject: Re: fflush() on readonly files X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2004 10:59:44 -0000 On Sat, Jun 19, 2004 at 11:56:43AM +0200, Radim Kolar wrote: > Today I have stepped on another example: advancecomp (in ports): > 543 * Get the size of the file. > 544 */ > 545 long fzsize(adv_fz* f) > 546 { > 547 if (f->type == fz_file) { > 548 struct stat st; > 549 if (fflush(f->f) != 0) { > 550 return -1; > 551 } This program relies on undocumented behaviour and should be fixed in anycase. Besides of that the only reasonable approach we can take is to do what majority of systems does here. Since you are interested in the subject, please post specific table for all main systems in the form like: System readonly fflush() behaviour -- Andrey Chernov | http://ache.pp.ru/ From owner-freebsd-arch@FreeBSD.ORG Sat Jun 19 11:59:24 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8DCC16A4CE for ; Sat, 19 Jun 2004 11:59:23 +0000 (GMT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAF6443D2D for ; Sat, 19 Jun 2004 11:59:23 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (211.26.207.166) by smtp01.syd.iprimus.net.au (7.0.024) id 40B7A0DA0064A281 for freebsd-arch@freebsd.org; Sat, 19 Jun 2004 21:58:55 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id F2D6D41CB; Sat, 19 Jun 2004 22:01:49 +1000 (EST) Date: Sat, 19 Jun 2004 22:01:49 +1000 From: Tim Robbins To: freebsd-arch@freebsd.org Message-ID: <20040619120149.GA64515@cat.robbins.dropbear.id.au> References: <20040609154040.GA26229@asura.bsd> <20040610021356.GA4990@VARK.homeunix.com> <20040610025439.GA11655@cat.robbins.dropbear.id.au> <20040619095642.GA67130@sanatana.dharma> <20040619105938.GA69596@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040619105938.GA69596@nagual.pp.ru> User-Agent: Mutt/1.4.1i Subject: Re: fflush() on readonly files X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2004 11:59:24 -0000 On Sat, Jun 19, 2004 at 02:59:39PM +0400, Andrey Chernov wrote: > On Sat, Jun 19, 2004 at 11:56:43AM +0200, Radim Kolar wrote: > > Today I have stepped on another example: advancecomp (in ports): > > 543 * Get the size of the file. > > 544 */ > > 545 long fzsize(adv_fz* f) > > 546 { > > 547 if (f->type == fz_file) { > > 548 struct stat st; > > 549 if (fflush(f->f) != 0) { > > 550 return -1; > > 551 } > > This program relies on undocumented behaviour and should be fixed in > anycase. Besides of that the only reasonable approach we can take is to do > what majority of systems does here. Since you are interested in the > subject, please post specific table for all main systems in the form > like: > > System readonly fflush() behaviour This has already been discussed: - Microsoft libraries and other libraries imitating them discard buffered input data (like fpurge().) - UNIX libc (at least 7th ed.), Solaris libc, GNU libc and products derived from P.J. Plauger's C library (e.g. QNX) do nothing and indicate success. - BSD since Torek's stdio rewrite (inc. FreeBSD and Mac OS X) indicate an error. There is no reason to change from the perfectly correct & well-documented behaviour BSD has had for 10-15 years. The original poster's example provides a good argument for this: it detects application bugs. Tim From owner-freebsd-arch@FreeBSD.ORG Sat Jun 19 13:07:29 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9E2516A4CE; Sat, 19 Jun 2004 13:07:29 +0000 (GMT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AC4C43D53; Sat, 19 Jun 2004 13:07:29 +0000 (GMT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.11/8.12.11) with ESMTP id i5JD7J39071718; Sat, 19 Jun 2004 17:07:19 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.11/8.12.11/Submit) id i5JD7JM3071717; Sat, 19 Jun 2004 17:07:19 +0400 (MSD) (envelope-from ache) Date: Sat, 19 Jun 2004 17:07:18 +0400 From: Andrey Chernov To: Tim Robbins Message-ID: <20040619130718.GA71593@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Tim Robbins , freebsd-arch@FreeBSD.ORG References: <20040609154040.GA26229@asura.bsd> <20040610021356.GA4990@VARK.homeunix.com> <20040610025439.GA11655@cat.robbins.dropbear.id.au> <20040619095642.GA67130@sanatana.dharma> <20040619105938.GA69596@nagual.pp.ru> <20040619120149.GA64515@cat.robbins.dropbear.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040619120149.GA64515@cat.robbins.dropbear.id.au> User-Agent: Mutt/1.5.6i X-AntiVirus: checked by AntiVir Milter 1.1-beta; AVE 6.25.0.62; VDF 6.25.0.102 (host: pobrecita.freebsd.ru) cc: freebsd-arch@FreeBSD.ORG Subject: Re: fflush() on readonly files X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2004 13:07:30 -0000 On Sat, Jun 19, 2004 at 10:01:49PM +1000, Tim Robbins wrote: > This has already been discussed: > - Microsoft libraries and other libraries imitating them discard buffered > input data (like fpurge().) Damn them. > - UNIX libc (at least 7th ed.), Solaris libc, GNU libc and products derived > from P.J. Plauger's C library (e.g. QNX) do nothing and indicate success. We need to do the same again (at least until some standard says otherwise). > - BSD since Torek's stdio rewrite (inc. FreeBSD and Mac OS X) indicate > an error. We need to fix just fflush() case only, left other rewrite parts untouched. if ((fp->_flags & (__SWR | __SRW)) == 0) retval = 0; > There is no reason to change from the perfectly correct & well-documented > behaviour BSD has had for 10-15 years. The original poster's example provides > a good argument for this: it detects application bugs. I agree. -- Andrey Chernov | http://ache.pp.ru/ From owner-freebsd-arch@FreeBSD.ORG Sat Jun 19 13:30:00 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9199716A4CE; Sat, 19 Jun 2004 13:30:00 +0000 (GMT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id D83DF43D53; Sat, 19 Jun 2004 13:29:59 +0000 (GMT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.11/8.12.11) with ESMTP id i5JDTONk071972; Sat, 19 Jun 2004 17:29:24 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.11/8.12.11/Submit) id i5JDTOkm071971; Sat, 19 Jun 2004 17:29:24 +0400 (MSD) (envelope-from ache) Date: Sat, 19 Jun 2004 17:29:24 +0400 From: Andrey Chernov To: Tim Robbins , freebsd-arch@FreeBSD.ORG Message-ID: <20040619132924.GA71908@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Tim Robbins , freebsd-arch@FreeBSD.ORG References: <20040609154040.GA26229@asura.bsd> <20040610021356.GA4990@VARK.homeunix.com> <20040610025439.GA11655@cat.robbins.dropbear.id.au> <20040619095642.GA67130@sanatana.dharma> <20040619105938.GA69596@nagual.pp.ru> <20040619120149.GA64515@cat.robbins.dropbear.id.au> <20040619130718.GA71593@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040619130718.GA71593@nagual.pp.ru> User-Agent: Mutt/1.5.6i X-AntiVirus: checked by AntiVir Milter 1.1-beta; AVE 6.25.0.62; VDF 6.25.0.102 (host: pobrecita.freebsd.ru) Subject: Re: fflush() on readonly files X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2004 13:30:00 -0000 On Sat, Jun 19, 2004 at 05:07:18PM +0400, Andrey Chernov wrote: > > - BSD since Torek's stdio rewrite (inc. FreeBSD and Mac OS X) indicate > > an error. > > We need to fix just fflush() case only, left other rewrite parts > untouched. > > if ((fp->_flags & (__SWR | __SRW)) == 0) > retval = 0; > > > There is no reason to change from the perfectly correct & well-documented > > behaviour BSD has had for 10-15 years. The original poster's example provides > > a good argument for this: it detects application bugs. > > I agree. It may sounds confusing. I mean I want to return to pre-Torek stdio rewrite state Unix (and BSD?) have for years. With big number of apps writen for Linux today nobody want to detect such "bugs" for the sake of standards vagueness but want to have working app. -- Andrey Chernov | http://ache.pp.ru/ From owner-freebsd-arch@FreeBSD.ORG Sat Jun 19 13:35:27 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0AB616A4CE; Sat, 19 Jun 2004 13:35:27 +0000 (GMT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2277143D1D; Sat, 19 Jun 2004 13:35:27 +0000 (GMT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.11/8.12.11) with ESMTP id i5JDZOUM072088; Sat, 19 Jun 2004 17:35:24 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.11/8.12.11/Submit) id i5JDZO7Y072083; Sat, 19 Jun 2004 17:35:24 +0400 (MSD) (envelope-from ache) Date: Sat, 19 Jun 2004 17:35:24 +0400 From: Andrey Chernov To: Tim Robbins , freebsd-arch@FreeBSD.ORG Message-ID: <20040619133524.GA72030@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Tim Robbins , freebsd-arch@FreeBSD.ORG References: <20040609154040.GA26229@asura.bsd> <20040610021356.GA4990@VARK.homeunix.com> <20040610025439.GA11655@cat.robbins.dropbear.id.au> <20040619095642.GA67130@sanatana.dharma> <20040619105938.GA69596@nagual.pp.ru> <20040619120149.GA64515@cat.robbins.dropbear.id.au> <20040619130718.GA71593@nagual.pp.ru> <20040619132924.GA71908@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040619132924.GA71908@nagual.pp.ru> User-Agent: Mutt/1.5.6i X-AntiVirus: checked by AntiVir Milter 1.1-beta; AVE 6.25.0.62; VDF 6.25.0.102 (host: pobrecita.freebsd.ru) Subject: Re: fflush() on readonly files X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2004 13:35:28 -0000 On Sat, Jun 19, 2004 at 05:29:24PM +0400, Andrey Chernov wrote: > > > There is no reason to change from the perfectly correct & well-documented > > > behaviour BSD has had for 10-15 years. The original poster's example provides > > > a good argument for this: it detects application bugs. > > > > I agree. Moreover, I agree that it is incorrect (i.e. beyond of standard scope) assumption from program side, but what the fix you suggest? There is no _standard_ way to detect by given FILE * pointer is it R or W, there is no such standard stdio macro. -- Andrey Chernov | http://ache.pp.ru/