From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 16 17:49:07 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAD3F16A4B3 for ; Tue, 16 Sep 2003 17:49:07 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23FE143FA3 for ; Tue, 16 Sep 2003 17:49:07 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h8H0n6Dm001535; Tue, 16 Sep 2003 20:49:06 -0400 (EDT) Date: Tue, 16 Sep 2003 20:49:06 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Dan Langille In-Reply-To: <3F67714D.32262.7B04653@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org Subject: Re: [PATCH] : libc_r/uthread/uthread_write.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2003 00:49:08 -0000 On Tue, 16 Sep 2003, Dan Langille wrote: > I've had preliminary success with this patch. More testing needs > to be done, but in the meantime, I would appreciate reviews and > comments. The patched code is available from > http://beta.freebsddiary.org/tmp/uthread_write.c and the patch > appears below. > > In short, the logic has been changed to ensure that if __sys_write > returns zero, this value is returned by _write. I think this is not quite correct. Since libc_r is looping and some data may have been read, then the partial byte count should be returned, not zero. It is possible the partial byte count could also be zero in some cases, so it would result in zero being returned in those instances. I think the problem lies with the SCSI tape device. It should either return 0 or -1 with errno=ENOSPC on a write that detects an EOT, not partial byte count. If you are using libkse or libthr, you will get a partial byte count and not zero because the tape driver returns the (partial) bytes written. So exiting the loop in libc_r and returning 0 would only seem to correct the "problem" for libc_r. -- Dan Eischen