ping

[Joel Sherrill]

Charles Steaderman wrote:
> 
> Sounds right to me. There are some types which also need to be
> declared (quad_t and in_addr_t).

quad_t is defined in rtems_bsdnet_internal.h which is only for 
inside the stack and drivers.  Hmmm.. any ideas on this one Eric?

I don't see in_addr_t at all.  

> Once the timer functions are
> implemented, should the signal stuff work?  

If the signals are defined at all to a number then yes.  SIGALARM
works because alarm() works.  SIGVTALRM and SIGPROF are not defined
in the rtems part of newlib's sys/signal.h.  Which signal does ping use?
Eric N and I reworked this set recently for some stuff he needed to 
support (ncurses?).  Maybe he has thoughts here also.

> What about "command line"
> argument processing? Should I rename main() 

Yes.  Probably something like ping_main().

> and handle parameters in
> some other way than argc/argv?

No.  Just pass them in the same format to it.  Build up the arguments
as an array and pass it to ping_main.
 
> - Charlie
> 
> Joel Sherrill wrote:
> 
> > Charles Steaderman wrote:
> >
> >
> >> Has anyone ported ping to RTEMS? I couldn't find anything in the
> >> archives. I started, but am not sure if signals will work as
> >> expected,
> >> and I am not sure about a replacement function for setitimer. Any
> >> thoughts?
> >>
> >>
> > I assume you mean the client program for ping.
> >
> > I would recommend not modifying ping and providing implementations
> > of
> > getitimer() and setitimer() which were implemented using
> > rtems_timer_create()
> > and rtems_timer_fire_after().
> >
> > Since each process is supposed to support 3 timers, I would
> > recommend
> > adding
> > the fields to the rtems_user_env_t structure and managing it that
> > way.
> >
> > The general RTEMS rule of thumb is for RTEMS to implement missing
> > standard
> > routines where possible in a logical and coherent way rather than
> > modifying
> > packages when porting them.  So in this case, implementing the two
> > missing
> > routines is easier and safer than attempting to modify ping.  Plus
> > it
> > makes
> > the next porting job easier.
> >
> >
> >
> >> - Charlie
> >>
> >>
> > --joel
> >
> >
> >
> >
> 
> --
> Charlie Steaderman
> charlies at poliac.com
> VP Engineering
> Poliac Research Corporation
> Phone: 952.707.6245
> Cel: 612.242.6364