From owner-freebsd-net Wed May 13 12:24:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA27432 for freebsd-net-outgoing; Wed, 13 May 1998 12:24:48 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA27408 for ; Wed, 13 May 1998 12:24:36 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id PAA02837 for ; Wed, 13 May 1998 15:24:37 -0400 (EDT) Date: Wed, 13 May 1998 15:24:36 -0400 (EDT) From: "Matthew N. Dodd" To: freebsd-net@FreeBSD.ORG Subject: WIDE/KAMI IPv6 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ok, for kicks I've been reviewing the KAMI and INRIA IPv6 stuff and have a few questions/comments on the KAMI code I've seen so far. What kind of crack prompted the need to do this: + #ifdef INET6 + in6_ifattach(&sc->arpcom.ac_if, IN6_IFT_802, + (caddr_t)sc->arpcom.ac_enaddr, 0); + #endif /* INET6 */ + in -every- 'supported' network driver's XXinit function. Is there any reason this code does not belong in ifattach() or ether_ifattach()? I may have an ungrounded opinion here but IMHO none of the networking protocols should have to muck with the actual drivers that transport their packets (save SLIP and PPP maybe and even then.) I was more or less under the impression (from reading code) that the established means of passing data from one layer to another was via XXX_output() / XXX_input() routines. /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message