Date: Thu, 28 Jan 1999 14:08:30 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: net@FreeBSD.ORG, Archie Cobbs <archie@whistle.com> Subject: Re: netgraph... Message-ID: <Pine.BSF.3.95.990128133208.11856A-100000@current1.whistle.com> In-Reply-To: <513.917558171@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm starting to side with poul..
that's why nodes already have the 'status' command
(poul.. the 'status message asks the node to report back status in HUMAN
READABLE FORM.,
e.g.
[JulianIJ.whistle.com] 51 ngctl
socket name is ngctl13852:
ngctl> status fra0:
status response for fra0:
1096458 bytes in, 871344 bytes out
highest rate seen: 3486 B/S in, 2532 B/S out
ngctl>
On Thu, 28 Jan 1999, Poul-Henning Kamp wrote:
> In message <199901282051.MAA03721@bubba.whistle.com>, Archie Cobbs writes:
> >Poul-Henning Kamp writes:
> >> I'm not sure which control messages you are talking about, but if
> >> they are anything like what I expect, I don't see why they would
> >> have to be in argc+argv format, they are communication between
> >> programs.
> >>
> >> The configuration on the other hand is between a human and a
> >> program, which is why argc+argv makes sense in my eyes.
> >
> >We are in total agreement.
>
> Good, then why do you want to make the "ascii->internal format" code
> so very special ? Put it in the drivers source where it belongs and
> avoid all the complexity of separating that code out to other sections
> to run in user-land and all that stuff. It is pointless! You have
> to validate the stuff anyway, there is no net saving in code size,
> only increased complexity.
When I designed all this, The problem I was not able to solve before we
needed the code, was exactly this..
How to make a single user tool be able to handle arbitrary (new?) nodes
that it may know nothing about.
My short term answers included:
1/ make a set of generic functions that all nodes could do.
2/ allow nodes to change their behaviour according to how they are
attached to other nodes. (e.g. our sync card can do frame relay
on it's own but unfortunatly it doesn't support one protocol variant we
sometimes run into, so we do it in software. but the node will turn on
it's own proccessing if you attach to the "dlci16" node instead of the
"rawdata" hook).
3/ The node specific support for the 'status' command.
If I were to continue in this vein then the logical extension would be:
4/ An optional node specific "Configure" command that accepts a single
text configuration field, interpretted by the node. Note many nodes
wouldn't need this as nodes are designed to be simple. teh complexity
comes from the way you combine them.
In a related thought however, nodes that need to communicate between
each other should probably use compiled messages with specific message
codes.
It is much easier to believe that nodes sending status/control information
between themselves might do it a lot quicker and more often than
humans running ngctl. One node might be 'tuning' another in such a way
that there are many (hundereds?) of these messages per second?
In the same vein, if a process is doing this job it is assumed that it is
probably closely tied with the node in question and probably has the
apprpriate messages compiled in. This leaves us with only the human
generated control information. Now, admittedly there needs to be a human
way of doing everything that nodes can be doing themselves, but it does
point towards the neccesity of an (optional) interpretter per node.
Now the question is:
where does it go?
If it's inthe kernel, then there is no technology leap needed. Maybe there
may be support in the base module so things are not duplicated. If it's in
userland then there are two answers.
1/ the model used by mount... mount_codafs and fsck in sysV fsck_ufs
A separate process is fired off to handle the encoding.
2/ the loadable function model
2A/ held in the .ko file
2B/ held in a special file elsewhere.
julian
>
> --
> Poul-Henning Kamp FreeBSD coreteam member
> phk@FreeBSD.ORG "Real hackers run -current on their laptop."
> FreeBSD -- It will take a long time before progress goes too far!
>
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.3.95.990128133208.11856A-100000>