Date: Wed, 7 Jan 2015 21:04:29 +0000 From: "Robert N. M. Watson" <rwatson@FreeBSD.org> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: svn-src-head@freebsd.org, John-Mark Gurney <jmg@funkthat.com>, src-committers@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r276750 - in head: share/man/man9 sys/contrib/ipfilter/netinet sys/dev/an sys/dev/bge sys/dev/ce sys/dev/cm sys/dev/cp sys/dev/cs sys/dev/ctau sys/dev/ed sys/dev/ex sys/dev/fe sys/dev/h... Message-ID: <B8E4C537-3404-4477-97C9-D6C0C8495304@FreeBSD.org> In-Reply-To: <20150107204853.GH15484@FreeBSD.org> References: <201501061259.t06CxcTc096488@svn.freebsd.org> <20150107174430.GQ1949@funkthat.com> <alpine.BSF.2.11.1501071814350.36266@fledge.watson.org> <20150107204853.GH15484@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7 Jan 2015, at 20:48, Gleb Smirnoff <glebius@FreeBSD.org> wrote: > R> > Shouldn't this come w/ a FreeBSD version bump for drivers to use? > R>=20 > R> Yes, probably. Old drivers will continue to work fine in not = checking the=20 > R> return value (for now), but drivers seeing backporting will = probably want a=20 > R> __FreeBSD_version ifdef. I'll do a commit to bump the version = number today. > R>=20 > R> (In my local tree, M_EXT is renamed _M_EXT unless MBUF_PRIVATE is = defined,=20 > R> which really is quite a significant KPI change -- I'm not yet sure = if I'm=20 > R> going to push that into FreeBSD 11 or not.) >=20 > IMO, you should do the push :) >=20 > The faster we refactor the mbuf KPI, the better. Better do the surgery = in > one fast cut rather then do it in an endless serie of small but = painful > cuts. >=20 > Note that I'm still hoping of pushing projects/ifnet to 11, which is > a much bigger KPI change from drivers. The problem is really in structuring the changes so that they can be = reviewed: they're very hard to test since they touch dozens (hundreds?) = of drivers making them almost impossible to test effectively. Instead, = I've been breaking them down into a series of less intrusive and easier = to review chunks. The MLEN/MHLEN/MCLBYTES change should go into = phabricator this evening, assuming a bunch of sanity tests run to = completion successfully over the next few hours. These changes are = really all just to facilitate underlying changes to the mbuf allocator = by hiding more of the implementation details from consumers, so I want = to get them done in as expedient a manner as I can -- after all, they = are a bit boring :-). Robert=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B8E4C537-3404-4477-97C9-D6C0C8495304>