From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 09:19:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E98F1065676 for ; Tue, 2 Sep 2008 09:19:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0CD228FC25 for ; Tue, 2 Sep 2008 09:19:56 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1759F46C2A; Tue, 2 Sep 2008 05:19:55 -0400 (EDT) Date: Tue, 2 Sep 2008 10:19:55 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Debarshi Ray In-Reply-To: <3170f42f0809020017k643180efte155a5b5701a40cf@mail.gmail.com> Message-ID: References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE7B2.4050409@FreeBSD.org> <48BCE4AA.6050807@elischer.org> <3170f42f0809020017k643180efte155a5b5701a40cf@mail.gmail.com> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD networking and TCP/IP list , "Bruce M. Simpson" , Julian Elischer Subject: Re: reading routing table X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 09:19:57 -0000 On Tue, 2 Sep 2008, Debarshi Ray wrote: >> unfortunatly netstat -rn uses /dev/kmem > > Yes. I also found that FreeBSD's route(8) implementation does not have an > equivalent of 'netstat -r'. NetBSD and GNU/Linux implementations have such > an option. Any reason for this? Is it because you did not want to muck with > /dev/kmem in route(8) and wanted it to work with PF_ROUTE only? I have not > yet gone through NetBSD's route(8) code though. Usually the "reason" for things like this is that no one has written the code to do otherwise :-). PF_ROUTE is probably not a good mechanism for any bulk data transfer due to the constraints of being a datagram socket, although doing it via an interated dump rather than a simple dump operation would probably work. Sysctl is generally a better interface for monitoring for various reasona, although it also has limitations. Maintaining historic kmem support is important, since it is also the code used for interpreting core dumps, and we don't want to lose support for that. Robert N M Watson Computer Laboratory University of Cambridge