From owner-freebsd-current Sat Aug 24 12:26:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA24057 for current-outgoing; Sat, 24 Aug 1996 12:26:17 -0700 (PDT) Received: from eel.dataplex.net (EEL.DATAPLEX.NET [199.183.109.245]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA24050 for ; Sat, 24 Aug 1996 12:26:14 -0700 (PDT) Received: from [199.183.109.242] (cod [199.183.109.242]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id OAA28091; Sat, 24 Aug 1996 14:26:06 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 24 Aug 1996 14:26:06 -0500 To: Garrett Wollman From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: cvs commit: src/sys/netinet in.h ip_fw.h ip_input.c ip_output.c Cc: current@FreeBSD.org Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk ><Wackerbarth) said: > >> I suspect that Terry's point was that the hook mechanism need not be ip >> specific. Rather, any communications stack, for example appletalk, could >> use the same mechanism. I would anticipate that the filters would prefer to >> do their "type checking" at registration time and only register for those >> protocols that they are prepared to handle. > >Sounds like you're trying to make the IP processing path slower. This >thread got started because there's already too much junk cluttering >things up. I disagree that it would make things slower. Any protocol stack can reasonably have the same structure for the message buffers. They can also have the same structure for "hooks". It does not slow things down at all in processing a packet to have a generic "call hook" which calls an IP specific hook that knows itself to be registered in a path which handles only IP. The extra overhead in the registration mechanism is not significant and, besides, happens only once. On the other hand, there might be some value in being able to use a common hook that, for example, is sniffing MAC addresses or counting bytes transferred.