Date: Sat, 30 Jan 1999 12:27:10 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Archie Cobbs <archie@whistle.com> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, net@FreeBSD.ORG Subject: Re: netgraph... Message-ID: <Pine.BSF.4.05.9901301222140.348-100000@s204m82.isp.whistle.com> In-Reply-To: <199901301910.LAA09983@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9901301222140.348-100000>