joel.sherrill at OARcorp.com
Fri Apr 11 17:30:26 UTC 2003
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
More information about the users