From owner-cvs-all Fri Jul 23 1:30: 9 1999 Delivered-To: cvs-all@freebsd.org Received: from dingo.cdrom.com (castles505.castles.com [208.214.165.69]) by hub.freebsd.org (Postfix) with ESMTP id CF9C214BE1; Fri, 23 Jul 1999 01:30:05 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id BAA00709; Fri, 23 Jul 1999 01:22:55 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907230822.BAA00709@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Poul-Henning Kamp Cc: Mike Smith , Peter Jeremy , cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, jkh@FreeBSD.org Subject: Re: cvs commit: src/release/sysinstall tcpip.c In-reply-to: Your message of "Fri, 23 Jul 1999 10:10:58 +0200." <33651.932717458@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Jul 1999 01:22:54 -0700 From: Mike Smith Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > > I would advocate the ether_input API. I have never heard of a 3rd > party ethernet driver, and considering the number of changes we > introduce between 3.x and 4.x anyway, driver compatibility is > already pretty much shot anyway, so I think we should fix the > API to do it "right" rather than fight for a compatibility which > is at best of only marginal advantage to anybody. Ok. I did a lot of driving this evening, and while I was out on the road I was rolling this around in my head. The only reason I can see for ether_input to take the mbuf (with the header pruned) and a separate pointer to the header would be for ethernet hardware that does trailing encapsulation (sticks the header at the end rather than the beginning of the returned data). I can't see any drivers that do this in our tree. Further, the header has to be in the same storage as the rest of the data (otherwise we get leakage because only the mbuf is ultimately freed). So is there any reasonable expectation that we will have to deal with hardware that won't result in the driver placing the ethernet header immediately before the payload in the mbuf? This would result in us having to copy it around, which would be slightly yucky. BTW, there are a couple of third-party network drivers kicking around, but as you've pointed out so very much of the rest of the API has changed here. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message