On Monday, February 21, 2011 19:31:48 Rob Landley wrote: > On 02/21/2011 06:03 PM, Mike Frysinger wrote: > > On Friday, February 11, 2011 21:34:22 Rob Landley wrote: > >> Why do you want to have two user-visible symbols that mean exactly the > >> same thing? (What part of my explanation was incorrect?) > > > > no, the "has mmu" is there for the kconfig tree to make the the "use mmu" > > available to the user. the source then keys off of "use mmu". nowhere > > does the user select "i have a mmu", they only select "i want to use the > > mmu". seems pretty straightforward to me. > > Do a "make allnoconfig", then select target architecture "arm". > > Now go to the "target architecture features and options menu", > and confirm the following cut and paste: > > │ │ Target ABI (OABI) ---> │ > │ │ │ Target Processor Type (Generic Arm) ---> > │ │ │ │ Target File Format (FDPIC ELF) ---> > │ │ │ │ Target Processor Endianness (Big Endian) ---> > │ │ │ │ [*] Target CPU has a memory management unit (MMU) > │ │ │ │ [ ] Do you want to utilize the MMU? > │ │ │ │ [ ] Enable floating point number support > │ │ │ │ (/usr/include) Linux kernel header location > > There is ARCH_HAS_MMU, user selectable, and ARCH_USE_MMU, > being separately user selectable.
ok, for ambiguous arches, that's true > There is no reason for both symbols to even EXIST, let alone > the user having to separately select both of them. it makes the intention pretty clear. at the time, common code was frequently getting the idea of "having" and "using" wrong. plus, you had to manually select either "i have an mmu" or "i do not have an mmu". since the rewording, ive hardly seen the source go wrong, or the selection be confusing. i also vaguely recall the Kconfig syntax not working out correctly, but i'd have to play to figure out what exactly necessitated the split ... perhaps the issue has shaken itself out since. back to the point, perhaps the two could be merged in some form, but there is 0 harm in having two explicit symbols. it lets the Kconfig arches explicitly select options without ultimately screwing the user (which was happening in the past). in the 5 years since i first added this, i havent heard anyone complain or mention issues with it. all i see in this thread is you complaining about practical irrelevance. i'm not inclined to research something that has been proven to work to satisfy that one case. > this is just arm, it's not like anybody actually _uses_ > the single most common CPU type on the planet... no, it isnt just arm, as the trivial kconfig logic shows. any arch that has both MMU and NOMMU ports makes it an option. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
