From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16004 invoked by alias); 17 Jul 2006 19:33:55 -0000 Received: (qmail 15991 invoked by uid 22791); 17 Jul 2006 19:33:54 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 17 Jul 2006 19:33:52 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6HJXnDk019741 for ; Mon, 17 Jul 2006 15:33:49 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6HJXmad032574; Mon, 17 Jul 2006 15:33:49 -0400 Received: from [172.16.14.227] (IDENT:GXPIfrPd2g27xC1tfQUAPdGEESDweaIu@topaz.toronto.redhat.com [172.16.14.227]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id k6HJXmve029209; Mon, 17 Jul 2006 15:33:48 -0400 Message-ID: <44BBE61C.8000907@redhat.com> Date: Mon, 17 Jul 2006 19:33:00 -0000 From: Dave Brolley User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) MIME-Version: 1.0 To: "Frank Ch. Eigler" CC: sid@sources.redhat.com Subject: Re: [patch][commit] EOF Handling for sid-io-stdio References: <44B7F619.7040404@redhat.com> <20060714205725.GJ20476@redhat.com> In-Reply-To: <20060714205725.GJ20476@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact sid-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sid-owner@sourceware.org X-SW-Source: 2006-q3/txt/msg00022.txt.bz2 Frank Ch. Eigler wrote: >Hi - > > > >>I've committed this patch which corrects a problem with >>sid-io-stdio. Currently, when there is no data available to be >>read, the gloss component cannot distinguish this from EOF. [...] >> >> > >Interesting, I vaguely recall intending that code to encode EOF the >same way C stdio does (value 0..255: valid data, value -1: eof). The >data pin is wide enough to do so unambiguously. > > > I see what you're saying, but I still think that an eof pin is a better interface. 1) No overhead on the receiving end examining each value driven on the data pin to see if it's the magic '-1' character 2) Driving the eof pin could easily trigger additional events, if needed. Dave