On 02/12/2011 12:01 AM, Khem Raj wrote: > On (10/02/11 13:42), Rob Landley wrote: >> I mentioned that my build was dying due to trying to use -mfdpic which >> is a target-specific option for the FRV processor: >> >> http://lists.uclibc.org/pipermail/uclibc/2011-January/044701.html >> https://bugs.busybox.net/show_bug.cgi?id=3193 >> >> The problem is that uClibc has an utterly useless user-visible >> "TARGET_HAS_MMU" as well as "TARGET_USE_MMU", and I took the first out >> of miniconfig because I'd complained about the redundant option during >> the dev cycle and thought it was gone. > > hmmm yeah seems notion of using mmu and having mmu could be combined. > The case where chip has mmu but one still would like to not use it > can be deemed as > > TARGET_HAS_MMU is not set
I don't see why the MMU choice and the floating point coprocessor choice are significantly different at the design level. We don't have separate "has floating point" and "would like to use floating point" symbols. >From the C library's point of view, it's a binary decision. The kernel may need to know an FPU is there just so it can quiesce the thing even if it's not adding extra register saves to each process context switch. But from the C library's point of view either the kernel's giving it access to a working MMU, or it isn't. > I dont see any particular use of knowing that I have mmu when I dont > want to use it I could just about imagine the kernel needing to do something to get the MMU out of the way, so it needs to know it's there even when it's not going to set up page tables. But the kernel is not the C library. From libc's point of view you either have one or you don't. Having two different user visible config options for the same choice is strange and confusing. Rob _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
