Date: Mon, 1 Feb 1999 05:33:09 -0600 (CST) From: Richard Wackerbarth <rkw@dataplex.net> To: Archie Cobbs <archie@whistle.com> Cc: net@FreeBSD.ORG, phk@critter.freebsd.dk, julian@whistle.com Subject: Re: netgraph... Message-ID: <Pine.BSF.4.05.9902010505500.51597-100000@nomad.dataplex.net> In-Reply-To: <199902010618.WAA25673@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 31 Jan 1999, Archie Cobbs wrote:
> Richard Wackerbarth writes:
> > Is it so "complicated" to export a template (eg. format string)
> > in response to a single call to the node?
>
> That wouldn't be, but the worry is that templates might not
> be a powerful enough "language" to cover all the possibilities.
> Any "language" to do this would have to be so complicated
> that it would essentially be a programming language, so
> why not just export a perl script? :-) (that was a rhetorical
> question :-)
Because I like {tcl | python | lisp | java} better :-) [tongue-in-cheek]
> > And, using your scheme, how do I compute the time interval between two
> > messages? Do you propose to convert ALL packet fields for EVERY packet in
> > a dump? Even if I care about only one or two fields?
>
> The translation to and from ASCII could be done off-line, like
> the way tcpdump can do it, for example.
Unless I missed something, therein lies a problem. You have no way to
do it off-line. The only translator is on-line. In tcpdump's case, the
binary==>ASCII translation is already "off-line" (in the user code).
Although you can do it "non-real-time", you still need to be on-line
to the node to get its translation service.
> In general, control
> messages will always be in binary format until/unless a human
> wants to see them. Then they can be translated in "human time".
That still begs the translation question. It appears that you still have
to pass EACH message back into the kernel and get the entire translation
of the message. I assume that you would then parse that to extract the
field(s) of interest.
My point is that your scheme works only in those cases that the desired
action is to simply display the entire message (eg. syslog). Anything else
would still require that the userland program have knowledge of the
message structure.
I thought that the purpose of this facility was to provide a mechanism
that is both extensible and guaranteed to be the correct revision. That is
accomplished by having the translation DEFINITION bound to the node.
As for the actual language, how does this problem fundamentally differ
from the snmp MIB?
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9902010505500.51597-100000>