tty.cdl

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

tty.cdl

Ilija Kocho [Илија Кочо]
Hello colleagues

I need to extend tty.cdl in order to accommodate more than 4 serial
ports, currently I need 6. I can simply add 2 port entries but i would
prefer something like the snippet below. Either case I am ready to post
to Bugzilla.
Note: Similar case is with termios.cdl

Please advise.

Regards
Ilija
   
--- CDL snippet for tty.cdl -----------

    cdl_component CYGPKG_IO_SERIAL_TTY_TTY[set ::channel] {
        display       "TTY mode channel #[set ::channel]"
        flavor        bool
        default_value 0
        description   "
        This option causes '/dev/tty[set ::channel]' to be included in
the standard
        drivers."
       
        cdl_option CYGDAT_IO_SERIAL_TTY_TTY[set ::channel]_DEV {
            display       "TTY mode channel #[set ::channel] device"
            flavor        data
            default_value [ format { "\"/dev/ser%d\"" } $::channel ]
            description   "
            This option selects the physical device to use for
            '/dev/tty[set ::channel]'."
        }
    }
--- Snipped end -------------

Reply | Threaded
Open this post in threaded view
|

Re: tty.cdl

Sergei Gavrikov-4
On Sat, 26 Mar 2011, Ilija Kocho wrote:

> Hello colleagues
>
> I need to extend tty.cdl in order to accommodate more than 4 serial
> ports, currently I need 6. I can simply add 2 port entries but i would
> prefer something like the snippet below. Either case I am ready to post
> to Bugzilla.
> Note: Similar case is with termios.cdl
>
> Please advise.
 
Hi Ilija,

It seems your issue cannot be solved by editing the config files *only*.
There are a couple of hardwired conditional definitions for device table
entries there, take a look at

  $ECOS_REPOSITORY/io/serial/<version>/src/common/tty.c
  $ECOS_REPOSITORY/io/serial/<version>/src/common/termiostty.c


Sergei
Reply | Threaded
Open this post in threaded view
|

Re: tty.cdl

Ilija Kocho [Илија Кочо]
On 26.03.2011 19:32, Sergei Gavrikov wrote:

> On Sat, 26 Mar 2011, Ilija Kocho wrote:
>
>> Hello colleagues
>>
>> I need to extend tty.cdl in order to accommodate more than 4 serial
>> ports, currently I need 6. I can simply add 2 port entries but i would
>> prefer something like the snippet below. Either case I am ready to post
>> to Bugzilla.
>> Note: Similar case is with termios.cdl
>>
>> Please advise.
>  
> Hi Ilija,
>
> It seems your issue cannot be solved by editing the config files *only*.
> There are a couple of hardwired conditional definitions for device table
> entries there, take a look at
>
>   $ECOS_REPOSITORY/io/serial/<version>/src/common/tty.c
>   $ECOS_REPOSITORY/io/serial/<version>/src/common/termiostty.c
>
>
> Sergei
Hi Sergei

Thanks for the notes. I tried to extend this concept to tty.c, please
see attached CDL. Here are my questions.

1. The proc output is in io-serial.h and is protected to instantiate in
only file that defines __CYGSEM_FILE_IS_IO_SERIAL_COMMON_TTY_C (tty.c)
I would ask if it is possible to redirect puts to other file?

2. This may be question for John.
CYGOPT_IO_SERIAL_PROC_INCREMENTER interface is used as a stealth
container for define_proc.
I guess this is not a typical usage of cdl_interface. Could it cause a
trouble?

Note: I haven't tested compilation yet, only header generation. If this
approach is considered acceptable I would produce required changes in
tty.c and post a bug on Bugzilla.

Regards
Ilija

tty.cdl (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: tty.cdl

Sergei Gavrikov-4
On Sun, 27 Mar 2011, Ilija Kocho wrote:

> On 26.03.2011 19:32, Sergei Gavrikov wrote:
> > On Sat, 26 Mar 2011, Ilija Kocho wrote:
> >
> >> Hello colleagues
> >>
> >> I need to extend tty.cdl in order to accommodate more than 4 serial
> >> ports, currently I need 6. I can simply add 2 port entries but i would
> >> prefer something like the snippet below. Either case I am ready to post
> >> to Bugzilla.
> >> Note: Similar case is with termios.cdl
> >>
> >> Please advise.
> >  
> > Hi Ilija,
> >
> > It seems your issue cannot be solved by editing the config files *only*.
> > There are a couple of hardwired conditional definitions for device table
> > entries there, take a look at
> >
> >   $ECOS_REPOSITORY/io/serial/<version>/src/common/tty.c
> >   $ECOS_REPOSITORY/io/serial/<version>/src/common/termiostty.c
> >
> >
> > Sergei
> Hi Sergei
>
> Thanks for the notes. I tried to extend this concept to tty.c, please
> see attached CDL. Here are my questions.
>
> 1. The proc output is in io-serial.h and is protected to instantiate in
> only file that defines __CYGSEM_FILE_IS_IO_SERIAL_COMMON_TTY_C (tty.c)
> I would ask if it is possible to redirect puts to other file?
 
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

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?

I dislike a complicated Tcl programming in eCos config files (however,
this is mine).

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
Reply | Threaded
Open this post in threaded view
|

Re: tty.cdl

Ilija Kocho [Илија Кочо]

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

Reply | Threaded
Open this post in threaded view
|

Re: tty.cdl

Sergei Gavrikov-4
On Sun, 27 Mar 2011, Ilija Kocho wrote:

> 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?!

Indeed. But, now I think that I gave bad suggest about extension via
environment variable (How to document this "feature"? Who will know
about? It looks like a trick) Ilija, so far, I take a timeout to think
and test your substitutions and I will try to find compromise solution
without the tricks and complex Tcl/CDL expressions.


Sergei
Reply | Threaded
Open this post in threaded view
|

Re: tty.cdl

Ilija Kocho [Илија Кочо]
On 27.03.2011 19:11, Sergei Gavrikov wrote:

> On Sun, 27 Mar 2011, Ilija Kocho wrote:
>
>> 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?!
> Indeed. But, now I think that I gave bad suggest about extension via
> environment variable (How to document this "feature"? Who will know
> about? It looks like a trick) Ilija, so far, I take a timeout to think
> and test your substitutions and I will try to find compromise solution
> without the tricks and complex Tcl/CDL expressions.
>
Thanks,
In meantime I have a code that compiles and works. I will post to
Bugzilla so we can continue there.

Ilija

Reply | Threaded
Open this post in threaded view
|

Re: tty.cdl

Sergei Gavrikov-4
On Sun, 27 Mar 2011, Ilija Kocho wrote:

> On 27.03.2011 19:11, Sergei Gavrikov wrote:
> > On Sun, 27 Mar 2011, Ilija Kocho wrote:
> >
> >> 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?!
> > Indeed. But, now I think that I gave bad suggest about extension via
> > environment variable (How to document this "feature"? Who will know
> > about? It looks like a trick) Ilija, so far, I take a timeout to think
> > and test your substitutions and I will try to find compromise solution
> > without the tricks and complex Tcl/CDL expressions.
> >
> Thanks,
> In meantime I have a code that compiles and works. I will post to
> Bugzilla so we can continue there.
>
> Ilija

I was writing the below a few minutes ago

Ilija, I tried something and I see that your request can be managed with
CDL property 'make' and external Tcl script to generate some kind of
io_serial_tty.inl on a fly like eCos 'heapgen.tcl' generates that
heap.hxx, but I have a doubt about such a "complexity". By other hand
the original tty and termios config files won't to have a mess with
complex scripting as all details can be hidden in the external Tcl
script. Eternal dilemma: Universality vs. Simplicity. I would prefer S.
here (c & p), but, this is my view only.

I think that you have to create bugzilla report is describing your issue
(=request) without a solution and then we will discuss the ways to
resolve the issue and I hope you will have more hands for that.

Thank you,
Sergei
Reply | Threaded
Open this post in threaded view
|

Re: tty.cdl

Ilija Kocho [Илија Кочо]
On 27.03.2011 21:39, Sergei Gavrikov wrote:

> On Sun, 27 Mar 2011, Ilija Kocho wrote:
>
>> On 27.03.2011 19:11, Sergei Gavrikov wrote:
>>> On Sun, 27 Mar 2011, Ilija Kocho wrote:
>>>
>>>> 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?!
>>> Indeed. But, now I think that I gave bad suggest about extension via
>>> environment variable (How to document this "feature"? Who will know
>>> about? It looks like a trick) Ilija, so far, I take a timeout to think
>>> and test your substitutions and I will try to find compromise solution
>>> without the tricks and complex Tcl/CDL expressions.
>>>
>> Thanks,
>> In meantime I have a code that compiles and works. I will post to
>> Bugzilla so we can continue there.
>>
>> Ilija
> I was writing the below a few minutes ago
>
> Ilija, I tried something and I see that your request can be managed with
> CDL property 'make' and external Tcl script to generate some kind of
> io_serial_tty.inl on a fly like eCos 'heapgen.tcl' generates that
> heap.hxx, but I have a doubt about such a "complexity". By other hand
> the original tty and termios config files won't to have a mess with
> complex scripting as all details can be hidden in the external Tcl
> script. Eternal dilemma: Universality vs. Simplicity. I would prefer S.
> here (c & p), but, this is my view only.
>
> I think that you have to create bugzilla report is describing your issue
> (=request) without a solution and then we will discuss the ways to
> resolve the issue and I hope you will have more hands for that.
>
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.

Thanks
Ilija.

> Thank you,
> Sergei

Reply | Threaded
Open this post in threaded view
|

Re: tty.cdl

Sergei Gavrikov-4
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
Reply | Threaded
Open this post in threaded view
|

Re: tty.cdl

Ilija Kocho [Илија Кочо]
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.

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

I think these would be all changes to tty.c

Should I continue this way?

Ilija

Reply | Threaded
Open this post in threaded view
|

Re: tty.cdl

Sergei Gavrikov-4
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).

Thank you,
Sergei
Reply | Threaded
Open this post in threaded view
|

Re: tty.cdl

Ilija Kocho [Илија Кочо]
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
Reply | Threaded
Open this post in threaded view
|

Re: tty.cdl

Sergei Gavrikov-4
On Mon, 28 Mar 2011, Ilija Kocho wrote:
> On 28.03.2011 14:16, Sergei Gavrikov wrote:

[snip]

> > IMO, it is good solution (please, submit a patch to eCos Bugzilla).
> Posted: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001180

Thank you. I'm on CC.

Sergei