Date: Sat, 2 Oct 2010 13:35:57 -0700 From: Juli Mallett <jmallett@FreeBSD.org> To: Rui Paulo <rpaulo@freebsd.org> Cc: Ryan Stone <rysto32@gmail.com>, Robert Watson <rwatson@freebsd.org>, FreeBSD Net <net@freebsd.org> Subject: Re: mbuf changes Message-ID: <AANLkTi=uxARo5O9MASrx9mg-39E2=x05RXxcKUB62JrB@mail.gmail.com> In-Reply-To: <9AD4923A-72AE-4FE3-A869-3AF8ECBF17E2@FreeBSD.org> References: <4C9DA26D.7000309@freebsd.org> <AANLkTim7oRyVYY3frn7=cn4Et8Acbcq9cXja_bR6YWvP@mail.gmail.com> <4CA51024.8020307@freebsd.org> <alpine.BSF.2.00.1010021627230.49031@fledge.watson.org> <9AD4923A-72AE-4FE3-A869-3AF8ECBF17E2@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Oct 2, 2010 at 12:07, Rui Paulo <rpaulo@freebsd.org> 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.. >> >> I have, and it's a massive change touching code all over the kernel in v= ast quantities. =A0While 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 i= t even harder for vendors with large local changes to the network stack to = keep up. > > I think it could also increase the kernel bug count. Unfortunately, we ca= n't do this incrementally. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=uxARo5O9MASrx9mg-39E2=x05RXxcKUB62JrB>