From owner-svn-src-all@FreeBSD.ORG Sat Nov 23 10:55:42 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 760B4B46; Sat, 23 Nov 2013 10:55:42 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 4ED41221F; Sat, 23 Nov 2013 10:55:42 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id 4614146B3C; Sat, 23 Nov 2013 05:55:35 -0500 (EST) Date: Sat, 23 Nov 2013 10:55:34 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Adrian Chadd Subject: Re: svn commit: r258328 - head/sys/net In-Reply-To: Message-ID: References: <201311182258.rAIMwEFd048783@svn.freebsd.org> <023E719B-1059-4670-8556-EBAC18A2F007@freebsd.org> <20131121000245.GA30549@onelab2.iet.unipi.it> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "src-committers@freebsd.org" , FreeBSD Net , "svn-src-all@freebsd.org" , George Neville-Neil , "freebsd-arch@freebsd.org" , "svn-src-head@freebsd.org" , Luigi Rizzo X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 10:55:42 -0000 On Wed, 20 Nov 2013, Adrian Chadd wrote: > We should migrate drivers to use a multi-input method where it's > appropriate. It's the same pain as if_transmit() is/was. > > I'd really like to avoid having hacky solutions like mbufs with magic types. > If we're going down that path, we should create a correct inline messaging > mechanism that includes arbitrary messages in the stream, where some may or > may not be mbufs. Magic mbufs just makes me want to tear out my eyes a > little. > > So, the reason I'd like to back it out is because we should be doing it via > a multi method with some type that represents an mbuf list. If George > doesn't mind, I'll add a multi input method, move this stuff into it, and > make ether_input just be single frames. My worry here is that the failure modes for easy oversights and bugs are quite subtle ones: mbuf leakage and data corruption. Our goal should be to shift as many as possible of those bugs to compiler-detected events (e.g., due to type checking), or where not possible, run-time detected events (e.g., due to easily detected non-NULL pointers). I'm OK with the current change staying in the tree for a few weeks on the path there, but I much prefer the world in which we use different symbols for different "types". This is especially important if we will have device driver vendors maintaining drivers across many versions (which we do): we really don't want a driver using ether_input for queue handoff in 11.x to just mysteriously leak mbufs in 10.x. Instead, the driver should fail to compile. Robert