[haiku-development] Re: GSoC ICMP implementation

"Alvarez, Alan SPC MIL USA FORSCOM" <alan.alvarez@xxxxxxxxxxx> wrote:
> > IIRC, these functions were introduced exactly for this purpose. 
> > Axel will probably tell you more.
> This makes sense and I thought this was the case too, but since the 
> idea topics says to
> "implement an error handling and propagation I though maybe that 
> wasn't necessarily its main
> purpose.

It was the purpose of introducing these functions, but I didn't put 
much thought into them when I added them; they might be a good way to 
solve this issue, but then they could also be not adequate and 
complete.
I'm not that familiar with the issue anymore right now, but I think the 
way I envisioned it was to have the ICMP module register itself as 
error module to the domain (ie. ipv4 in this case), and would then 
automatically be used by the other protocols without a direct knowledge 
between the two.
Of course, this would only then work nicely, if they actually can 
operate more or less independently of each other, which I am not 
entirely sure about right now either. It's been a while, sorry.
In any case, the implementation should be good enough to be usable for 
Path-MTU discovery and of course cover all the needs of the UDP 
protocol.

> Is Axel in this list? or should I direct my questions to the 
> development list?

I'm subscribed to the other list as well, I was just on a vacation :-)

> Also, I have one more question, What is the best way to output 
> messages (somewhere) for
> debugging purposes so that I can verify something I implement is 
> actually working? I've seen
> a macro DTRACE being used around the code but I'm not sure where 
> exactly this is to be
> output(d). Should I enable debugging somewhere?
> From what I can tell the built-in kernel debugger stops the system so 
> this wouldn't help much
> since all I need is to see some simple debug messages.

That depends on your configuration. One way is to use (from the kernel 
and kernel modules) dprintf(). It's output is by default send to the 
serial output, as well as to the syslog.
If you develop under VMware or Qemu, or have a second system you can 
use as a serial debugging console, this should work well. If you only 
have a single Haiku system, you would need to look into the syslog for 
the output (under /var/log/syslog).

HTH,

Bye,
   Axel.

Other related posts: