From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 15:57:39 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 56EF916A41C for ; Mon, 13 Jun 2005 15:57:39 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AECA43D4C for ; Mon, 13 Jun 2005 15:57:36 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: Y1QAsIk9O44SO+J/q9KNyQ== Received: from mp-217-233-35.daxnet.no ([193.217.233.35] verified) by mailfe06.swip.net (CommuniGate Pro SMTP 4.3.2) with ESMTP id 383553762; Mon, 13 Jun 2005 17:57:33 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Mon, 13 Jun 2005 17:58:24 +0200 User-Agent: KMail/1.7 References: <200506131412.38967.hselasky@c2i.net> <20050613124427.GD1343@britannica.bec.de> In-Reply-To: <20050613124427.GD1343@britannica.bec.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506131758.25671.hselasky@c2i.net> Cc: Joerg Sonnenberger Subject: Re: Obvious bug in /sys/i386/include/bus.h (was: bus_at386.h) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2005 15:57:39 -0000 On Monday 13 June 2005 14:44, Joerg Sonnenberger wrote: > On Mon, Jun 13, 2005 at 02:12:38PM +0200, Hans Petter Selasky wrote: > > This is equivalent to: > > > > while(--count) > > { > > /* I/O */ > > } > > > > which is obviously wrong, because it doesn't check for count equal to > > zero. > > Why do you think it is a bug? It is part of the interface contract and > useful to avoid an unnecessary check in 99% of the cases. > Where is it documented? This is a bug, because it will break standard FIFO design. Consider the following pseudo code: static void filter(struct fifo *f) { do { if(!f->len) { if(f->m) ...; f->m = get_mbuf(); if(!f->m) break; f->len = m->m_len; f->ptr = m->m_data; } /* f->Z_chip is the maximum transfer length */ io_len = min(f->len, f->Z_chip); bus_space_write_multi_1(t,h,xxx,f->ptr,io_len); f->len -= io_len; f->Z_chip -= io_len; f->ptr += io_len; } while(Z_chip); } This code is going to crash if "f->Z_chip" or "f->len" is zero. That happens when one is trying to send or receive a zero length frame or mbuf. So then one can argue wether one should allow zero length frames or not. I argue that zero length frames should be allowed, because it enables easy stream synchronization: For example to signal end of stream, send a frame less than 16 bytes. Maximum frame length is 16 bytes. If a stream is exactly 16 bytes long, then one has to send one 16 byte frame and one 0 byte frame. Also zero length frames can be used as a kind of heart-beat. Adding that extra check for zero transfer length is not going to affect performance at all. If one does that using "C", the compiler can optimize away that "if(count) ..." when "count" is a constant. Besides the i386 machine instructions "ins" and "outs" already exhibit that behaviour. --HPS