<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
Sounds right to me. There are some types which also need to be declared (quad_t
and in_addr_t). Once the timer functions are implemented, should the signal
stuff work? What about "command line" argument processing? Should I rename
main() and handle parameters in some other way than argc/argv?<br>
<br>
- Charlie<br>
<br>
Joel Sherrill wrote:<br>
<blockquote type="cite" cite="mid3E96F4F8.5FFD8667@OARcorp.com">
<pre wrap="">
Charles Steaderman wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">- Charlie
</pre>
</blockquote>
<pre wrap=""><!---->
--joel
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="$mailwrapcol">--
Charlie Steaderman
<a class="moz-txt-link-abbreviated" href="mailto:charlies@poliac.com">charlies@poliac.com</a>
VP Engineering
Poliac Research Corporation
Phone: 952.707.6245
Cel: 612.242.6364</pre>
</body>
</html>