Date: Tue, 16 Sep 2003 20:49:06 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Dan Langille <dan@langille.org> Cc: hackers@freebsd.org Subject: Re: [PATCH] : libc_r/uthread/uthread_write.c Message-ID: <Pine.GSO.4.10.10309162041380.28900-100000@pcnet5.pcnet.com> In-Reply-To: <3F67714D.32262.7B04653@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10309162041380.28900-100000>