Date: Wed, 7 Dec 2016 06:35:39 +0100 From: Michal Meloun <melounmichal@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r309531 - head/sys/arm/include Message-ID: <7ed22afe-65de-f6b0-22fe-7c34e2663694@freebsd.org> In-Reply-To: <1802951.O895X1uuQH@ralph.baldwin.cx> References: <201612041527.uB4FRduc064051@repo.freebsd.org> <1802951.O895X1uuQH@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
Because I'm stupid enough to not remember that we have code which is compiled only as module. So my standard 'make buildkernel -DNO_CLEAN -DNO_MODULES' is not a best option how to test this new code. And rest is only natural result of panic caused by 'I break a kernel build' and 'I have scheduled a meeting @work at now'. You are right of course, I will fix it later today. Michal On 06.12.2016 23:01, John Baldwin wrote: > On Sunday, December 04, 2016 03:27:39 PM Michal Meloun wrote: >> Author: mmel >> Date: Sun Dec 4 15:27:39 2016 >> New Revision: 309531 >> URL: https://svnweb.freebsd.org/changeset/base/309531 >> >> Log: >> Implement fake pmap_mapdev_attr() for ARMv6. >> This function is referenced, but never called from DRM2 code. Also, >> real behavior of pmap_mapdev_attr() in ARM world is unclear as we don't >> have any additional attribute for a device memory type. >> >> MFC after: 2 weeks > One more question: why not define this in pmap.c instead of an inline > function in the header file? (The inline bit seemed to have led to several > followups due to build breakage and the "fixes" require a fair bit of header > pollution.) >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7ed22afe-65de-f6b0-22fe-7c34e2663694>