From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31375 invoked by alias); 29 May 2008 22:52:46 -0000 Received: (qmail 31338 invoked by uid 22791); 29 May 2008 22:52:45 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 29 May 2008 22:52:20 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1K1qyn-0000Rx-RH for ecos-discuss@sources.redhat.com; Thu, 29 May 2008 22:52:17 +0000 Received: from 64.251.14.41 ([64.251.14.41]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 May 2008 22:52:17 +0000 Received: from grante by 64.251.14.41 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 May 2008 22:52:17 +0000 To: ecos-discuss@sources.redhat.com From: Grant Edwards Date: Thu, 29 May 2008 22:52:00 -0000 Message-ID: References: <20080529183205.GD22071@lunn.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: slrn/pre0.9.9-102 (Linux) X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: [ECOS] Re: A "pipe" like object for eCos? X-SW-Source: 2008-05/txt/msg00109.txt.bz2 On 2008-05-29, Andrew Lunn wrote: > On Thu, May 29, 2008 at 06:27:30PM +0000, Grant Edwards wrote: >> I find myself in need of a "pipe" like object in an eCos >> application (one that doesn't have file I/O and Posix support >> enabled). All I need is a simple circular buffer in RAM with >> blocking and non-blocking read/write methods. Am I correct in >> my conclusion that eCos doesn't have something like that as >> part of it's core functionality? >> >> I haven't found anything like that in the docs, but I thought >> I'd double-check before I go off and write something... > > There was a pipe implementation contributed. I spent some time > cleaning it up a few years ago. Try the attachment. > > Andrew > > [begin attachment: pipe.tgz] The following code looks odd: 287 // -------------------------------------------------------------------------- 288 // Implement Flush/Drain controls 289 290 static Cyg_ErrNo 291 pipe_get_config(cyg_io_handle_t handle, 292 cyg_uint32 key, void *buf, cyg_uint32 * len) 293 { 294 cyg_devtab_entry_t *devtab = (cyg_devtab_entry_t *) handle; 295 PIPE_INFO_S *pipeInfo = (PIPE_INFO_S *) devtab->priv; 296 Cyg_ErrNo retVal = ENOERR; 297 298 switch (key) { 299 // clear the buffer and signal any threads waiting. 300 case CYG_IO_GET_CONFIG_SERIAL_INPUT_FLUSH: 301 case CYG_IO_GET_CONFIG_SERIAL_OUTPUT_FLUSH: 302 case CYG_IO_GET_CONFIG_SERIAL_OUTPUT_DRAIN: 303 cyg_drv_mutex_lock(&pipeInfo->lock); 304 pipeInfo->writeIndex = 0; 305 pipeInfo->readIndex = 0; 306 pipeInfo->dataLength = 0; 307 cyg_drv_cond_broadcast(&pipeInfo->wait); 308 #ifdef CYG_IO_PIPE_SELECT_SUPPORT 309 cyg_selwakeup(&pipeInfo->selinfoTx); 310 #endif 311 cyg_drv_mutex_unlock(&pipeInfo->lock); 312 retVal = ENOERR; 313 break; 314 315 default: 316 retVal = -EINVAL; 317 break; 318 } 319 320 return (retVal); 321 } It looks like all three of those flush/drain operations do the same thing: discard all of the data. I can see why both flush operations might discard the data, since it's not a directionless interface, but shouldn't the drain operation just block until the buffer is empty instead of discarding data? -- Grant Edwards grante Yow! PARDON me, am I at speaking ENGLISH? visi.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss