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>