Date: Fri, 29 Jan 1999 09:00:39 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Julian Elischer <julian@whistle.com> Cc: net@FreeBSD.ORG, Archie Cobbs <archie@whistle.com> Subject: Re: netgraph... Message-ID: <2105.917596839@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 28 Jan 1999 14:08:30 PST." <Pine.BSF.3.95.990128133208.11856A-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>My short term answers included: > >1/ make a set of generic functions that all nodes could do. yes, things like "attach", "dettach", "debug" and so on. >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). urg. POLA may be in danger here... >3/ The node specific support for the 'status' command. Should return standard struct (for stuff in 1/ and stats) and ascii string for custom stuff. >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. Well, I would make it an argc+argv arg, but that is a minor detail. >In a related thought however, nodes that need to communicate between >each other should probably use compiled messages with specific message >codes. absolutely. >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? I fail to come up with an example right now. Opening and closing VCs is the best I can come up with, and most protocols deliberately make sure that only happens on a 10s of seconds/minutes time scale (for accounting reasons). >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. yes. >This leaves us with only the human >generated control information. I would even say "quasi-static config info"... >Now the question is: >where does it go? I argue with KISS for "in the kernel". The area we're into here, is the "weirdo config args", things like telling cards to go into loop-back on channel 4, to select balanced or unbalanced connection, the speed of V.35 (for buffer estimation), ISDN switch type. All these highly irregular things that always ends up in the LINK[012] flags for interfaces and in the flags for isa devices. (If you look at most of the fooctrl programs, they are small, do almost nothing, and a general "ioctl" program which could pass an generic ioctl with an ascii argument to the driver would save us some code...) I can almost even live with the bloat of a "usage" control message which returns an ascii usage string. -- 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?2105.917596839>