From owner-freebsd-hackers Fri Oct 13 17:28:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA18366 for hackers-outgoing; Fri, 13 Oct 1995 17:28:05 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA18361 for ; Fri, 13 Oct 1995 17:28:02 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id RAA21872 for ; Fri, 13 Oct 1995 17:27:11 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id RAA09357 for hackers@freebsd.org; Fri, 13 Oct 1995 17:26:37 -0700 From: Julian Elischer Message-Id: <199510140026.RAA09357@ref.tfs.com> Subject: Re: generic kernel interfaces (e.g. proto_register) To: hackers@freebsd.org Date: Fri, 13 Oct 1995 17:26:37 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2010 Sender: owner-hackers@freebsd.org Precedence: bulk somehow this conversation ahs drifted off hackers.. but it's exactly the thing that should be on it. just redirecting it back there julian Forwarded message: > at the bottom end, incoming packets received on an interface..... > We need an extensible mechanism where a new protocol can > arrange to get it's packets sent to it > If we do a good enough job, then maybe even bpf can > use it (so we don't need to keep adding bpf support to drivers) > > I was thinking of the following.. it should be quick enough and > extensible enough.. > > A hash table for finding your protocol for incoming packets.. > (for each supported net type.. e.g ether would have one, > that is keyed off ETHERTYPE_xxx), and if the packet fails that > then there is a backup method which is a linked list of > 'match' routines.. The reasoning is that common protocols that have a > well defined ETHERTYPE value (e.g. arp, ip...) > can make a quick match on the table, but that something > more complicated such as 802.3 stuff might need to fall through > to a 802.3 match function which will either 'claim' it > or allow it to be passed on to the next function to try.. > if it runs out of those then it is dumped. This sounds ideal, actually. > going the other way, it should be possible to run ethernet and 802.3 > on the same interface, depending on the target host.. > I'm sure this info can be kept in the routing table, but I don't know > if we'd need to send two arp packets out.. one in each type.. > > the simple answer is of course a LINK flag indicating the differnce, > but I don't know if it it's accepted to limit a net to either one or > the other.. NetWare, UnixWare, VMS, and Ultrix all support multiple protocol types on an interface. One place to look might be at multicast, which has to do a similar thing. Where has Garrett Wollman been in this discussion?!? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.