Re: [PATCH] rename COMPAT_FREEBSD32

On Mar 23, 2010, at 7:05 AM, Nathan Whitehorn wrote:

>> On Mar 22, 2010, at 10:52 AM, David O'Brien wrote:
>> 
>>> / On Mon, Mar 15, 2010 at 09:00:18AM -0700, Julian Elischer wrote:
> />>>/ I certainly agree.. can it be changed please?
> />>/ />>/ I've waited a while to see what other opinions would be expressed on this
> />>/ topic.  I believe there is sufficient support to rename COMPAT_FREEBSD32
> />>/ to something else based on responses in the mailing lists.
> />>/ />>/ I am sorry if some may wish to label this a "bikeshead".  But we seem to
> />>/ have many folks disliking "COMPAT_FREEBSD32".
> />>/ />>/ />>/ Based on responses to the topic of COMPAT_FREEBSD32, the following
> />>/ were the suggestions offered:
> />>/    COMPAT_ARCH32, COMPAT_ARCH_32BIT, COMPAT_32BIT_ARCH, COMPAT_32BIT,
> />>/    COMPAT_FREEBSD32BIT
> />
>> There's probably a bigger problem than just how we name it. The option
>> really encodes 2 independent aspects:
>> 1.  Support for a 32-bit ABI (i.e. ILP32)
>> 2.  Support for a particular OS in ILP32.
>> 
>> Of course 2 implies 1.
>> 
>> For example:
>> COMPAT_IA32 in sys/ia64/ia64/machdep.c enabled code to save and restore
>> IA32 registers as part of cpu_switch(). In this context COMPAT_IA32 was
>> perfectly named. It's now called COMPAT_FREEBSD32, which doesn't make a
>> lot of sense because what if I only want to support Linux/ia32 and not
>> FreeBSD/ia32 (or vice-versa if you club them under a single COMPAT_*32)?
> 
> The original version of my my patch had this split, with a COMPAT_FREEBSD32
> and a COMPAT_[IA/PPC/MIPS]32. The problem is that the 32-bit FreeBSD compat is
> deeply intertwined with providing support for any 32-bit binaries at all (e.g.,
> the 32-bit linuxolator depends on calling into it), so it isn't actually possible
> to support having COMPAT_LINUX32 without COMPAT_FREEBSD32 without a huge amount
> of work. So I scrapped that in favor of the unified name only, and we
> ended up with COMPAT_FREEBSD32.

I understand. I just wonder if it was wise to expose this dependency
across the whole source base with COMPAT_FREEBSD32 rather than keep
it local to the linuxulator. What if we remove the dependency at some
later point in time? Then what we have left is COMPAT_FREEBSD32 for
no reason other than hysterical raisins.

Anyway... Just want to point out that it's probably not a good idea
to have a single option for multiple features, even if the code has
them intertwined. Code changes easily, but options typically don't.

<out-on-a-limb>
Maybe we should improve our config to include dependencies, so that
one only has to add "options INVARIANTS" and config knows to include
"options INVARIANT_SUPPORT". It's not uncommon for option/device X
to need or depend on option/device Y...
</out-on-a-limb>

-- 
Marcel Moolenaar
xcllnt_at_mac.com