From owner-freebsd-net@FreeBSD.ORG Sat Oct 2 23:29:25 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5333106566C; Sat, 2 Oct 2010 23:29:25 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 63A538FC1B; Sat, 2 Oct 2010 23:29:25 +0000 (UTC) Received: from d.earth.lavabit.com (d.earth.lavabit.com [192.168.111.13]) by karen.lavabit.com (Postfix) with ESMTP id A033811B887; Sat, 2 Oct 2010 18:29:24 -0500 (CDT) Received: from 10.0.10.3 (221.163.108.93.rev.vodafone.pt [93.108.163.221]) by lavabit.com with ESMTP id 7HXEFN76VTP1; Sat, 02 Oct 2010 18:29:24 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: Date: Sun, 3 Oct 2010 00:29:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0DB8120D-C02A-49A1-8013-1ED818EDE7E6@freebsd.org> References: <4C9DA26D.7000309@freebsd.org> <4CA51024.8020307@freebsd.org> <9AD4923A-72AE-4FE3-A869-3AF8ECBF17E2@FreeBSD.org> To: Juli Mallett X-Mailer: Apple Mail (2.1081) Cc: Ryan Stone , Robert Watson , FreeBSD Net Subject: Re: mbuf changes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 23:29:25 -0000 On 2 Oct 2010, at 21:35, Juli Mallett wrote: > On Sat, Oct 2, 2010 at 12:07, Rui Paulo wrote: >> On 2 Oct 2010, at 16:29, Robert Watson wrote: >>> On Thu, 30 Sep 2010, Julian Elischer wrote: >>>> On 9/30/10 10:49 AM, Ryan Stone wrote: >>>>> It's not a big thing but it would be nice to replace the m_next = and m_nextpkt fields with queue.h macros. >>>> funny, I've never even thought of that.. >>>=20 >>> I have, and it's a massive change touching code all over the kernel = in vast quantities. While in principle it's a good idea (consistently = avoid hand-crafted linked lists), it's something I'd discourage on the = basis that it probably won't significant reduce the kernel bug count, = but will make it even harder for vendors with large local changes to the = network stack to keep up. >>=20 >> I think it could also increase the kernel bug count. Unfortunately, = we can't do this incrementally. >=20 > Can't we? What about a union, so that we can gradually convert things > but keep ABI and API compatibility? I mean, as long as we use the > right queue.h type, anyway, it should be consistent? STAILQ, > presumably. Well, I don't have the layout of the mbuf struct offhand, but it's an = idea worth investigating. Regards, -- Rui Paulo