From owner-freebsd-net Sat Jan 30 13:59:50 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA20655 for freebsd-net-outgoing; Sat, 30 Jan 1999 13:59:50 -0800 (PST) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from nomad.dataplex.net ([208.2.87.8]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA20610 for ; Sat, 30 Jan 1999 13:59:40 -0800 (PST) (envelope-from rkw@dataplex.net) Received: from localhost (rkw@localhost) by nomad.dataplex.net (8.9.1/8.9.1) with ESMTP id PAA46305; Sat, 30 Jan 1999 15:57:36 -0600 (CST) (envelope-from rkw@dataplex.net) Date: Sat, 30 Jan 1999 15:57:35 -0600 (CST) From: Richard Wackerbarth To: Archie Cobbs cc: net@FreeBSD.ORG Subject: Re: netgraph... In-Reply-To: <199901302143.NAA10793@bubba.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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