>> IP is so you can make it through a cisco, etc. to another >> routable segment.
> Oh I know that; but the cost of that convenience seems high. > For us, with a lab full of test machines (used for simulating > and testing various IP network clouds) a non-IP solution was > preferable. > But I can see that for other situations (such as debugging a > machine colocated at your ISP, or debugging kernels in the > field (ouch!)) our solution is far from ideal. Still, adding > a separate tcp/ip stack just for debugging (as someone seemed > to suggest) seems excessive. You probably meant to say "udp/ip stack", no? While this is easier than tcp, it's still expensive in that you have to cooperate with applications which use IP. However, such a mechanism (kernel debugging integrated into the UDP/IP code) could also support things like SNMP directly to the kernel. Without involving user process scheduling, kernel-snmp could be very useful for remote management of machines who's resources are so overloaded that remote login is no longer possible. Invariably these are the times you really wish you could run "netstat", "ps", "vmstat" etc but you cant even get a prompt from the console. brad To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
