From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14657 invoked by alias); 28 Mar 2011 19:00:32 -0000 Received: (qmail 14636 invoked by uid 22791); 28 Mar 2011 19:00:31 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC X-Spam-Check-By: sourceware.org Received: from ctel-78-157-16-61.cabletel.com.mk (HELO relay.cabletel.com.mk) (78.157.16.61) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 28 Mar 2011 19:00:25 +0000 Received: from [192.168.209.21] (unknown [78.157.9.54]) by relay.cabletel.com.mk (Postfix) with ESMTP id CBD69BDD39 for ; Mon, 28 Mar 2011 21:04:30 +0200 (CEST) Message-ID: <4D90DAC3.3080209@siva.com.mk> Date: Mon, 28 Mar 2011 19:00:00 -0000 From: Ilija Kocho User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: ecos-devel@ecos.sourceware.org Subject: Re: tty.cdl References: <4D8DBE3F.2000708@siva.com.mk> <4D8F2207.7070701@siva.com.mk> <4D8F5BAD.6020708@siva.com.mk> <4D8F9147.10204@siva.com.mk> <4D8F963A.6050501@siva.com.mk> <4D9065F0.40201@siva.com.mk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-CableTel-MailScanner-Information: Please contact the ISP for more information X-CableTel-MailScanner-ID: CBD69BDD39.AF33D X-CableTel-MailScanner: Found to be clean X-CableTel-MailScanner-SpamScore: s X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2011-03/txt/msg00040.txt.bz2 On 28.03.2011 14:16, Sergei Gavrikov wrote: > On Mon, 28 Mar 2011, Ilija Kocho wrote: > >> On 27.03.2011 23:11, Sergei Gavrikov wrote: >>> On Sun, 27 Mar 2011, Ilija Kocho wrote: >>> >>>> Sergei, I started this discussion in order to discuss this issue before >>>> I drop any code. Your proposal sounds rational. I shall open a Bug and >>>> reference this discussion. >>> Ilija and may be not :-) I've seen that io_serial.h has >>> >>> #ifdef CYGDAT_IO_SERIAL_DEVICE_HEADER >>> # include CYGDAT_IO_SERIAL_DEVICE_HEADER >>> #endif >>> >>> So, your issue can be managed on the target's side, as both and tty.c >>> and termios.c include this header. You can add CDL component in your HAL >>> config file which parent should be CYGPKG_IO_SERIAL_TTY and define extra >>> devices (TTY4, TTY5, ...) there. Also define/set your own value for the >>> CYGDAT_IO_SERIAL_DEVICE_HEADER in the HAL's config file. >>> >> Sergei, thanks for remark. I tried it but produced file is included to >> early as table definitions such as >> >> DEVTAB_ENTRY(tty_io4, >> "/dev/tty4", >> CYGDAT_IO_SERIAL_TTY_TTY4_DEV, >> &tty_devio, >> tty_init, >> tty_lookup, // Execute this when device is being looked up >> &tty_private_info4); >> >> depend on definitions included afterwards. Also file io_serial.h is >> included in serial.c where produces errors. > > Yep. Then I noticed this catch too. > >> However the TTYs provided by devicel driver / HAL may be included at >> proper place in tty.c later in similar way: >> >> #ifdef CYGDAT_IO_SERIAL_TTY_ADD >> # include CYGDAT_IO_SERIAL_TTY_ADD >> #endif > Exactly. > >> I think these would be all changes to tty.c > and the same for termios.c. > >> Should I continue this way? > IMO, it is good solution (please, submit a patch to eCos Bugzilla). Posted: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001180 Thanks, Ilija