From owner-freebsd-net Wed Jun 27 16:42:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from coopcomp.com (coopcomp.com [161.58.219.43]) by hub.freebsd.org (Postfix) with ESMTP id 37DFF37B401 for ; Wed, 27 Jun 2001 16:42:51 -0700 (PDT) (envelope-from seichert@coopcomp.com) Received: from gourdy.coopcomp.com (gourdy.coopcomp.com [64.81.249.34]) by coopcomp.com (8.11.2) id f5RNgp442194; Wed, 27 Jun 2001 17:42:51 -0600 (MDT) Received: by gourdy.coopcomp.com (sSMTP sendmail emulation); Wed, 27 Jun 2001 16:42:45 -0700 Date: Wed, 27 Jun 2001 16:42:45 -0700 From: Stuart Eichert To: net@freebsd.org Subject: Re: Am I missing something? Message-ID: <20010627164245.B48973@gourdy.coopcomp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Jun 27, 2001 at 02:30:42PM -0500, Alfred Perlstein wrote: > Why not provide a patch that allows one to add callbacks to the list? > > for ether_output under the default case you would walk the list > looking for your type, since for the most part packets will be in > AF_INET and when no callbacks are registered the array will be > short, transmit should be cheap. For recieve if you look in > the default case you can see ng_ether_input_orphan_p being used to > input packets that don't match a known type. It was my feeling that a good idea might be to set aside a range of ETHERTYPEs for research/testing use. Put them after the normal ones, so that AF_INET and others will get checked for first (thus hopefully not harming performance for the normal case). The last case statement could be something that sees if the type is in the research range, and then if it is it could do some sort of lookup in a hash table/cache deal and then call the appropriate callback funcs. My goal for this project is to not only provide code for adding a network protocol to FreeBSD, but also document the process so that others can learn how to modify the network subsystem. In addition I would like to provide a framework for people to dynamically add and remove new protocols. If I was able to patch if_ethersubr (and probably a few others) to allow for these dynamically available protocols, what are the chances that the code would be committed and become part of FreeBSD 4.4 or 5.0? The reason I ask is that I would like to reduce the barriers to people using FreeBSD for this purpose. I would like to say to them "Hey install FreeBSD 4.4 with default settings, nothing special, download a few of these network protocol modules, load them, try the test apps" After they do that, hopefully they will read the documents about how to add protocols to FreeBSD, or at least use of the tools/libs I provide to add their own protocols. The intended market is researchers who may or may not currently use FreeBSD in their research. -- ------------ Stuart Eichert Cooperative Computers, Inc. seichert@coopcomp.com (650)938-0730 x 15 ----- End forwarded message ----- -- ------------ Stuart Eichert Cooperative Computers, Inc. seichert@coopcomp.com (650)938-0730 x 15 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message