Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 Sep 2008 10:19:55 +0100 (BST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Debarshi Ray <debarshi.ray@gmail.com>
Cc:        FreeBSD networking and TCP/IP list <freebsd-net@freebsd.org>, "Bruce M. Simpson" <bms@freebsd.org>, Julian Elischer <julian@elischer.org>
Subject:   Re: reading routing table
Message-ID:  <alpine.BSF.1.10.0809021017500.1150@fledge.watson.org>
In-Reply-To: <3170f42f0809020017k643180efte155a5b5701a40cf@mail.gmail.com>
References:  <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE7B2.4050409@FreeBSD.org> <48BCE4AA.6050807@elischer.org> <3170f42f0809020017k643180efte155a5b5701a40cf@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.1.10.0809021017500.1150>