From owner-freebsd-net Sat Jan 30 12:35:49 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA08585 for freebsd-net-outgoing; Sat, 30 Jan 1999 12:35:49 -0800 (PST) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA08578 for ; Sat, 30 Jan 1999 12:35:48 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id MAA21983; Sat, 30 Jan 1999 12:27:19 -0800 (PST) Received: from s204m82.isp.whistle.com(207.76.204.82) via SMTP by alpo.whistle.com, id smtpdR21979; Sat Jan 30 20:27:13 1999 Date: Sat, 30 Jan 1999 12:27:10 -0800 (PST) From: Julian Elischer X-Sender: julian@s204m82.isp.whistle.com To: Archie Cobbs cc: Poul-Henning Kamp , net@FreeBSD.ORG Subject: Re: netgraph... In-Reply-To: <199901301910.LAA09983@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: > Poul-Henning Kamp writes: > > >The point is that you avoid having to parse ASCII strings > > >for *every* control message. > > > > I simply don't understand why we can't have a single type of > > controlmessage that means > > > > "Here is an ascii string to you from the super-user, do > > whatever he tells you to, thankyou!" > > > > That's what I'm asking for, no more, no less. > > (why is this so hard to communicate) > > Are you saying you really don't understand, or you just weigh the > priorities differently? > > The reason is: > > It's important that control message delivery between nodes be as > fast as possible (read: no encoding/decoding between binary and > ASCII for every message). This is so we can support situations > where there are hundreds of these messages flying around per second, > ie, for flow control or whatever. > > Maybe you don't care as much about this, but I do.. > > BUT, we can satisfy your need as well. We'll add a new base function: > > extern int ng_send_ascii_msg(node_p here, const char *path > const char *asciimsg, struct ng_mesg **rptr); > > This function will simply do this: > > int > ng_send_ascii_msg(ode_p here, const char *path > const char *asciimsg, struct ng_mesg **rptr) > { > struct ng_mesg decode_msg, *decode_reply; > int error; > > NG_MKMESSAGE(decode_msg, NGM_GENERIC_COOKIE, NGM_DECODE_MSG, > asciimsg, strlen(asciimsg)); > error = ng_send_msg(here, decode_msg, path, &decode_reply); > if (error != 0) > return(error); > return (ng_send_msg(here, decode_reply, path, rptr)); > } > > So the sender can chose how they want to encode their message. I'm afraid we're reaching an impass on this one Poul and I don't like it. I'm sure he understands what you are saying. (I can't give a reason, I just don't) I don't really want to see a parser in the kernel, but both your scheme and poul's (and one of mine) has it anyway, so if it's there, we might as well use it directly. My scheme to keep the parser OUT of the kernel and just use metadata from the node has also met with disaproval, so to my view the 'parser in the kernel' wins. It may be as simple as a single string parser or it may take argc,argv. that's a separate discussion. > > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message