Date: Tue, 8 Oct 2002 12:16:02 -0700 (PDT) From: Don Lewis <dl-freebsd@catspoiler.org> To: brandt@fokus.gmd.de Cc: nate@root.org, julian@elischer.org, tlambert2@mindspring.com, sam@errno.com, freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch Message-ID: <200210081916.g98JG2vU036242@gw.catspoiler.org> In-Reply-To: <20021008100826.H77302-100000@beagle.fokus.gmd.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8 Oct, Harti Brandt wrote: > On Mon, 7 Oct 2002, Don Lewis wrote: > DL>Why not name them? At boot or module load time stuff the name in a > DL>table and use the table index as the 16 bit ID. Is there any reason the > DL>ID has to be the same each time the system is booted? > > Well, the point is that you need a common name between netgraph nodes and > their controling application. As it is now this common name is the 32-bit > cookie generated by issuing "date -u +'%s'" (so no timezone problem here). > > I have, for example, an user space ILMI daemon for ATM. This daemon needs > to talk to the call control netgraph node. To do this the header file for > the call control node contains > > #define NGM_CCATM_COOKIE 984046139 > > both, the netgraph node and the daemon include this file and the daemon > addresses messages to the node by filling in the cookie into the > appropriate field in the message. The node filters out the messages by > compare the cookie field with the above cookie. In this implementation you also have to worry about collisions in the include file name, possibly the #define name, as well as the actual cookie. > If you use a dynamically generated cookie (be it a ++tags or a hash over a > string or the address of a kernel structure) both the user space > application and the node would need to call the code that generates these > cookies with just another cookie (for example a string). So what you would > do is to replace the 32-bit cookie with, for example, a string cookie. > > The question is, would a string cookie reduce the probability of conflicts > on cookies? This question is rather hard to answer, because on one hand > strings may contain more bits, but people would try to use descriptive and > short cookie. I see a very high probability of two people that develop a > ppp node to use the same string "ppp". This would be bad, because the > actual API they implement would for sure be different. With the above > method to choose the 32-bit cookie, this wouldn't happen. Given that the > netgraph-hype is not of the dimensions of the Java-hype two people > starting to develop netgraph node at the same moment of UTC is rather > improbable. Pick a convention for generating the string cookies: *printf(..., "netgraphid_%08x", 32bitnetgraphid) netgraph_brandt_ccatm_v1.234 netgraph_brandt_ccatm_`date -u` All of these allow different versions to simultaneously coexist. In the latter two examples if the API is rich enough and the proper naming convention is chosen, a client could even look to see if a "close enough" version is already installed. I see the problem of arranging the rendezvous between the user and kernel parts as totally separate from the tag that finally gets tacked onto each packet. The latter only has to be unique for the system uptime. > The only option that would make sense would be a assigned numbers > authority, but again, given the dimensions of the netgraph-hype - is it > worth the effort? If the proper naming convention is chosen, each author can have his own name space to play in, so no central authority is needed other than to allocate author names. 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?200210081916.g98JG2vU036242>