From: Ilija Kocho <ilijak@siva.com.mk>
To: ecos-devel@ecos.sourceware.org
Subject: Re: tty.cdl
Date: Sun, 27 Mar 2011 15:46:00 -0000 [thread overview]
Message-ID: <4D8F5BAD.6020708@siva.com.mk> (raw)
In-Reply-To: <alpine.DEB.2.00.1103271511250.8683@sg-laptop>
On 27.03.2011 14:45, Sergei Gavrikov wrote:
>
> Hi Ilija,
>
> I get it (about your attempting to build the in-lines using CDL), but, I
> would keep things simpler, i.e. just would add two absent entries for
> TTY4, TTY5, TTYx in tty.c. Those are conditional definitions depend on
>
Adding two additional TTYs is an alternative indeed, it is simple and
straightforward to implement.
My idea was to make system auto extensible and configurable. I have
fixed number of TTYs to 6, but as you suggest in your research below it
could be defined as a variable. HAL could provide an override too. Also
maintenance may be simpler since we avoid duplicated code?!
However there is the question of cost/benefit, this change may be too
radical - hence my dilemma what version to post as patch. Would it be
proper if I provide both alternatives?
> cdl_component CYGPKG_IO_SERIAL_TTY_TTYx {
> user_value 1
> };
>
> such things define itself if user enables TTYx
>
> pkgconf/io_serial.h:
> #define CYGPKG_IO_SERIAL_TTY_TTYx 1
> #define CYGDAT_IO_SERIAL_TTY_TTYx_DEV "/dev/serX"
>
> otherwise auto-generated io_serial.h header has no such definitions.
> Right?
They are present, but at wrong place - after code generated by puts. I
found-out it in meantime and I have changed CDL so define_proc/puts is
after cdl_option CYGDAT_IO_SERIAL_TTY_TTY[set ::channel]_DEV
The actual problem was only with CYGDAT_IO_SERIAL_TTY_TTYx_DEV.
CYGDAT_IO_SERIAL_TTY_TTYx_1 are not necessary since CDL will generate
only selected devices in io_serial.h
> I dislike a complicated Tcl programming in eCos config files (however,
> this is mine).
>
I have to admit that I like to avoid code replication whenever possible,
but this for {} pattern is present in some serial device diver CDLs so
it is not a precedent.
Should I take your research below as an encouragement?
> I tried such thing in config file
>
> if {! [info exist ::env(ECOS_MAX_TTY_DEVS)]} {;# check env variable
> set ::max_tty_devs 4
> } {
> set ::max_tty_devs $::env(ECOS_MAX_TTY_DEVS)
> }
>
> for { set ::device 0 } { $::device < $::max_tty_devs } { incr ::device } {
> cdl_component CYGPKG_IO_SERIAL_TTY_TTY[set ::device] {
> display "TTY mode channel #[set ::device]"
> flavor bool
> default_value 0
> ...
>
> and if I've configured eCos as
>
> % env ECOS_MAX_TTY_DEVS=6 ecosconfig new <target>
> % env ECOS_MAX_TTY_DEVS=6 ecosconfig tree
>
> I got 6 definitions for TTYs in eCos config. So, it was needed to add 2
> new entries in tty.c *only* (just c&p) to get things spin.
>
> Well, I tried
>
> % export ECOS_MAX_TTY_DEVS=6
> configtool
>
> and, I've seen in CT
>
> -[*] TTY mode serial device drivers
> ...
> + [ ] TTY mode for channel #0
> ...
> + [ ] TTY mode for channel #5
> + [ ] TTY mode for channel #6
>
> However, I have nothing against hardwired iterators in {,termios}tty.cdl
> For six? eight ports?
>
> for { set ::device 0 } { $::device < 6 } { incr ::device } {
> ...
>
> In any cases user should enable the Nth serial port for TTY/TERMIOS to
> get the record in pkgconf/io_serial.h and this header is included in
> tty.c and termiostty.c sources.
>
>
> Sergei
next prev parent reply other threads:[~2011-03-27 15:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-26 10:22 tty.cdl Ilija Kocho
2011-03-26 18:33 ` tty.cdl Sergei Gavrikov
2011-03-27 11:40 ` tty.cdl Ilija Kocho
2011-03-27 12:45 ` tty.cdl Sergei Gavrikov
2011-03-27 15:46 ` Ilija Kocho [this message]
2011-03-27 17:11 ` tty.cdl Sergei Gavrikov
2011-03-27 19:34 ` tty.cdl Ilija Kocho
2011-03-27 19:39 ` tty.cdl Sergei Gavrikov
2011-03-27 19:55 ` tty.cdl Ilija Kocho
2011-03-27 21:11 ` tty.cdl Sergei Gavrikov
2011-03-28 10:42 ` tty.cdl Ilija Kocho
2011-03-28 12:16 ` tty.cdl Sergei Gavrikov
2011-03-28 19:00 ` tty.cdl Ilija Kocho
2011-03-28 19:25 ` tty.cdl Sergei Gavrikov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D8F5BAD.6020708@siva.com.mk \
--to=ilijak@siva.com.mk \
--cc=ecos-devel@ecos.sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).