From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 16:07:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1BAD106566B; Tue, 23 Mar 2010 16:07:12 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout025.mac.com (asmtpout025.mac.com [17.148.16.100]) by mx1.freebsd.org (Postfix) with ESMTP id 73F488FC19; Tue, 23 Mar 2010 16:07:12 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp025.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KZQ00C2MSRTL1A0@asmtp025.mac.com>; Tue, 23 Mar 2010 09:07:06 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003230139 From: Marcel Moolenaar In-reply-to: <4BA8CA90.80208@freebsd.org> Date: Tue, 23 Mar 2010 09:07:05 -0700 Message-id: <0D26A59A-6D21-4FE6-84EC-F8458DD5AF0F@mac.com> References: <4BA8CA90.80208@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1077) Cc: FreeBSD-CURRENT Mailing List Subject: Re: [PATCH] rename COMPAT_FREEBSD32 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 16:07:13 -0000 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... -- Marcel Moolenaar xcllnt@mac.com