tty.cdl

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

Re: tty.cdl

[Sergei Gavrikov]

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

Re: tty.cdl

[Ilija Kocho]

[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]

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

[-- Attachment #2: tty.cdl --]
[-- Type: text/plain, Size: 5487 bytes --]

# ====================================================================
#
#      tty.cdl
#
#      eCos serial TTY configuration data
#
# ====================================================================
## ####ECOSGPLCOPYRIGHTBEGIN####                                            
## -------------------------------------------                              
## This file is part of eCos, the Embedded Configurable Operating System.   
## Copyright (C) 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc.
##
## eCos is free software; you can redistribute it and/or modify it under    
## the terms of the GNU General Public License as published by the Free     
## Software Foundation; either version 2 or (at your option) any later      
## version.                                                                 
##
## eCos is distributed in the hope that it will be useful, but WITHOUT      
## ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or    
## FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License    
## for more details.                                                        
##
## You should have received a copy of the GNU General Public License        
## along with eCos; if not, write to the Free Software Foundation, Inc.,    
## 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.            
##
## As a special exception, if other files instantiate templates or use      
## macros or inline functions from this file, or you compile this file      
## and link it with other works to produce a work based on this file,       
## this file does not by itself cause the resulting work to be covered by   
## the GNU General Public License. However the source code for this file    
## must still be made available in accordance with section (3) of the GNU   
## General Public License v2.                                               
##
## This exception does not invalidate any other reasons why a work based    
## on this file might be covered by the GNU General Public License.         
## -------------------------------------------                              
## ####ECOSGPLCOPYRIGHTEND####                                              
# ====================================================================
######DESCRIPTIONBEGIN####
#
# Author(s):      jskov
# Original data:  gthomas
# Contributors:   ilijak
# Date:           1999-07-07
#
#####DESCRIPTIONEND####
#
# ====================================================================

#define_header "tty_defices.inl"

cdl_component CYGPKG_IO_SERIAL_HALDIAG {
    display       "HAL/diag serial device driver"
    flavor        bool
    default_value 1
    description   "
        This option enables the use of the HAL diagnostic channel
        via the standard I/O drivers."
    compile       -library=libextras.a common/haldiag.c
}

cdl_option CYGDAT_IO_SERIAL_TTY_CONSOLE {
    display       "Console device name"
    flavor        data
    default_value {"\"/dev/ttydiag\""}
    description   "
        This option selects the TTY device to use for the console."
}

cdl_component CYGPKG_IO_SERIAL_TTY_TTYDIAG {
    display       "TTY mode HAL/diag channel"
    flavor        bool
    default_value 1
    description   "
        This option causes '/dev/ttydiag' to be included in the standard
        drivers."
}


# Proc index
set proc_i 0

# Workarround to prevent configtool crash
set __dev "_DEV"

for { set ::channel 0 } { $::channel < 6 } { incr ::channel } {
    
    cdl_interface CYGINT_IO_SERIAL_TTY_TTY[set ::channel] {
    }
    
    cdl_component CYGPKG_IO_SERIAL_TTY_TTY[set ::channel] {
        display       "TTY mode channel #[set ::channel]"
#        active_if CYGINT_IO_SERIAL_TTY_TTY[set ::channel]
        flavor        bool
        default_value 0
        
        define_proc {
            puts $::cdl_header ""
            puts $::cdl_header "#ifdef __CYGSEM_FILE_IS_IO_SERIAL_COMMON_TTY_C"
            puts $::cdl_header "static struct tty_private_info tty_private_info$proc_i;"
            puts $::cdl_header "DEVTAB_ENTRY(tty_io$proc_i,"
            puts $::cdl_header "    \"/dev/tty$proc_i\","
            puts $::cdl_header "    CYGDAT_IO_SERIAL_TTY_TTY$proc_i$__dev,"
            puts $::cdl_header "    &tty_devio,"
            puts $::cdl_header "    tty_init,"
            puts $::cdl_header "    tty_lookup,"
            puts $::cdl_header "    &tty_private_info$proc_i);"
            puts $::cdl_header "#endif // __CYGSEM_FILE_IS_IO_SERIAL_COMMON_TTY_C"
            puts $::cdl_header ""
        }
        
        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]'."
        }
    }
    cdl_interface CYGOPT_IO_SERIAL_PROC_INCREMENTER[set ::channel] {
        no_define
        define_proc {
            incr proc_i
        }
        description "Increment proc_i for every tty - active or inactive."
    }
}

cdl_interface CYGOPT_IO_SERIAL_PROC_ZERO {
    no_define
    define_proc {
        set proc_i 0
    }
    description "Reset proc_i for next save."
}

Re: tty.cdl

[Sergei Gavrikov]

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

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

Re: tty.cdl

[Sergei Gavrikov]

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

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

Re: tty.cdl

[Sergei Gavrikov]

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

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

Re: tty.cdl

[Sergei Gavrikov]

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

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

Re: tty.cdl

[Sergei Gavrikov]

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

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

Re: tty.cdl

[Sergei Gavrikov]

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