Date: Fri, 30 Jul 2010 01:37:46 -0700 From: Juli Mallett <jmallett@FreeBSD.org> To: "Jayachandran C." <c.jayachandran@gmail.com> Cc: freebsd-mips@freebsd.org Subject: Re: Support for 64bit userspace. Message-ID: <AANLkTinz-Gs-iojO9PYS%2BV3Qr-TPSfWhKCwnX9XN_rbq@mail.gmail.com> In-Reply-To: <AANLkTimOM-LmBChHPgU%2Bqa7Q_YFwc5ZYv7JkOfiV3FDU@mail.gmail.com> References: <AANLkTikZKS8iuST1dp5yfo6P6kaif4b1YzsKAskk_wB=@mail.gmail.com> <AANLkTinXdCLinp=07dsPYs3qr7nWJ6nZzKF5DV=z1R59@mail.gmail.com> <AANLkTinwi7v3wANCd5EGA9GHuWUrnAEP3Rq6EedGpGKe@mail.gmail.com> <20100729.131134.4959786895411328.imp@bsdimp.com> <AANLkTimOM-LmBChHPgU%2Bqa7Q_YFwc5ZYv7JkOfiV3FDU@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 30, 2010 at 01:15, Jayachandran C. <c.jayachandran@gmail.com> w= rote: > I will look at merging them without too many ifdefs. Another > possibility is to have a pmap.c, pmap32.c and pmap64.c, so that the > common code is not duplicated, but that too (as far as I can see) will > require a config option. I'm not really sure what the aversion to ifdefs is =97 they kind of come with the territory and this is exactly the part of the system where you expect to have them to conditionalize exactly this kind of behavior. If you were going to split out some subroutines for 32-bit and 64-bit, there are two ways you can do it without a config option (and I agree with you that avoiding one is very desirable =97 we already use too many knobs to get the right ABI in kernel configs). You could do: #ifndef __mips_n64 #include "pmap32.c" #else #include "pmap64.c" #endif Or you could wrap the whole 32/64 files (modulo a "struct __hack;" or whatever to avoid an empty translation unit) with ifdefs. Personally, I find having two implementations of a function a lot harder to read and keep track of than a single implementation with ifdefs in the body =97 there's very few places in the kernel where we do the former. If you do split out functions into separate files I would beg you to only split out the really big functions that are actually doing things based on different levels of page tables and then it's obvious why those things have two implementations and what needs to be abstracted to merge them. Having two copies of trivial functions or non-trivial functions that are mostly identical is a bad thing. You're doing the work, so at some point it's kind of your call, but I feel like you're making style changes to things that I cleaned up and tried to unify in pmap.c and that the way that they're done is pretty significant given how intimidating people find pmap. If we were going to support different kinds of MMUs (e.g. adding support for BAT-based MMUs) I'd be in favor of splitting things up, but then I'd want to follow PowerPC's lead. For now I think the appropriate thing to do is to follow the lead of my 64-bit work in the MIPS pmap and the PAE work in the i386 pmap and to use ifdefs and to try to abstract out the page-table differences. I'm really thrilled with the work you're doing and can't wait for it to be in head =97 I'm quite eager to move everything on Octeon to n64 :) Thanks, Juli.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinz-Gs-iojO9PYS%2BV3Qr-TPSfWhKCwnX9XN_rbq>