[PATCH] rename COMPAT_FREEBSD32
xcllnt at mac.com
Tue Mar 23 16:07:13 UTC 2010
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.
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...
xcllnt at mac.com
More information about the freebsd-current