Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 30 Jan 1999 15:57:35 -0600 (CST)
From:      Richard Wackerbarth <rkw@dataplex.net>
To:        Archie Cobbs <archie@whistle.com>
Cc:        net@FreeBSD.ORG
Subject:   Re: netgraph...
Message-ID:  <Pine.BSF.4.05.9901301548360.46007-100000@nomad.dataplex.net>
In-Reply-To: <199901302143.NAA10793@bubba.whistle.com>

next in thread | previous in thread | raw e-mail | index | archive | help


On Sat, 30 Jan 1999, Archie Cobbs wrote:

> Richard Wackerbarth writes:
> > Since we are all in (general) agreement that
> > 1: The node-node messages are in binary
> > 2: Only ngctl'ish programs need the ascii
> > 3: Their traffic is "low volume"
> > 
> > may I suggest moving much of this burden into
> > (a library of) ngctl.
> > 
> > Each node could be "read" to get the template
> > for its binary control messages. The "bloat" of
> > the actual parsing would be shifted to the parser
> > which remains in the ngctl program (library).
> > 
> > And if we could implement that in the node by
> > "dumping" the contents of its ELF "message format" section.
> 
> Well, we talked about that before (in private email) and came
> to the conclusion that anything requiring finagling with ELF
> sections was too complicated.

Certainly not necessary to have them in separate sections.
However, I don't expect that to remain difficult.
Once the mind-set is broken and the kernel starts to really use some of
the capabilities of ELF, it should be easy to do.
> 
> Nobody prefers having ASCII parsing code in the kernel, but
> it's worth the tradeoff if it buys you the ability to keep
> the parsing code and the rest of the node type code together.

By having the parsing meta-data delivered as a string from the node,
you can assure that the encoder matches the node. I assume that this is
the binding that concerns folks. (Making sure that the right
parser is available)

> However, if someday it becomes easy to do all of this:
> 
>   - Compile the encoding/decoding code into a separate ELF section
>   - Have kldload() not load the extra ELF section (it probably
>     already does this)
>   - Have ngctl dynamically find and link in the type's ELF section
>     containing the encode/decode routines
> 
> Then it might be worthwhile.. I think #1 and #3 are hard though
> (or at least, rather complicated).

Dynamic extensions to language parsers are rather common these days.
That is effectively what I would expect to see in the ngctl library.


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.9901301548360.46007-100000>