Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 05 Oct 2019 14:20:24 -0700
From:      Cy Schubert <Cy.schubert@cschubert.com>
To:        freebsd-arch@freebsd.org, Warner Losh <imp@bsdimp.com>, Shawn Webb <shawn.webb@hardenedbsd.org>
Subject:   Re: New CPUTYPE default for i386 port
Message-ID:  <06E29438-732D-4045-8FB3-5F2A082E9B98@cschubert.com>
In-Reply-To: <CANCZdfo6=r7BaGA8qKYSR9ba=azzxD%2ByDkN4aO87Oj1Qr9TKmA@mail.gmail.com>
References:  <CANCZdfoFPsjyuCTfm0dQhz%2BsgVHLEvMA8-E3-Yhciz67qdoKvw@mail.gmail.com> <20191005173411.l6gs3kszs7zcgfey@mutt-hbsd> <CANCZdfo6=r7BaGA8qKYSR9ba=azzxD%2ByDkN4aO87Oj1Qr9TKmA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On October 5, 2019 11:19:41 AM PDT, Warner Losh <imp@bsdimp=2Ecom> wrote:
>On Sat, Oct 5, 2019, 11:34 AM Shawn Webb <shawn=2Ewebb@hardenedbsd=2Eorg>
>wrote:
>
>> On Sat, Oct 05, 2019 at 09:28:53AM -0600, Warner Losh wrote:
>> > For a variety of reasons,  the time has come to change the default
>code
>> > generation arch from i486 to i686 on our i386 port=2E No actual code
>> removal
>> > is planned as part of this effort=2E Only the default is doing
>changed for
>> > clang=2E
>> >
>> > The practical upshot of this for our i386 users will be zero for
>almost
>> > everybody=2E For the tiny sliver of people planning to deploy FreeBSD
>on a
>> > i486 or i586 core, a simple addition of CPUTYPE=3Dxxxx to
>/etc/make=2Econf is
>> > all that is needed for the src side of things=2E They will need to
>setup
>> > their own poudriere instance and create their own pkg repo to build
>> > whatever packages are required for their deployment=2E
>> >
>> > It's my belief that even in the trailing edge long tail embedded
>> deployment
>> > segment of our user base this will cause no issues=2E All deployments
>there
>> > I'm aware of have moved of i486 class CPUs and the one 586 class
>core
>> > deployment I know of has no plans to update that to FreeBSD 11, let
>alone
>> > newer=2E
>> >
>> > There are a number of advantages to doing this which have been
>> articulated
>> > at length in other discussions=2E Briefly we get better code
>generation for
>> > CPUs people use and we avoid some test failures in llvm 9=2E0 because
>i486
>> > doesn't have 64-bot atomics=2E
>> >
>> > Comments?
>>
>> Full disclosure: I personally don't care about 32-bit architectures=2E
>> Feel free to ignore me based on that=2E ;-)
>>
>> I'm curious about the possibilities regarding 64-bit time_t on 32-bit
>> Intel systems=2E
>>
>
>Beyond the scope of this discussion=2E However, feel free to start a
>thread
>on this=2E It's quite difficult to switch if you want binary compat=2E It
>would
>affect system calls on the upgrade path and is among the hardest types
>to
>change if you have any kind of legacy to support=2E=2E=2E
>
>Warner
>
>
>Thanks,
>>
>> --
>> Shawn Webb
>> Cofounder / Security Engineer
>> HardenedBSD
>>
>> Tor-ified Signal:    +1 443-546-8752
>> Tor+XMPP+OTR:        lattera@is=2Ea=2Ehacker=2Esx
>> GPG Key ID:          0xFF2E67A277F8E1FA
>> GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23
>0FB2
>>
>_______________________________________________
>freebsd-arch@freebsd=2Eorg mailing list
>https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-arch
>To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd=2Eorg"

This is one of the two reasons I believe we should deprecate 32-bit=2E Eve=
n supporting 32-bit compatibility long term is unsustainable=2E It is not w=
orth the effort=2E

Putting a stake in the ground to say we no longer support 32-bit after 203=
8 would be desirable=2E (Sooner the better though=2E)


--=20
Pardon the typos and autocorrect, small keyboard in use=2E=20
Cy Schubert <Cy=2ESchubert@cschubert=2Ecom>
FreeBSD UNIX: <cy@FreeBSD=2Eorg> Web: https://www=2EFreeBSD=2Eorg

The need of the many outweighs the greed of the few=2E

Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E
From owner-freebsd-arch@freebsd.org  Sat Oct  5 22:50:38 2019
Return-Path: <owner-freebsd-arch@freebsd.org>
Delivered-To: freebsd-arch@mailman.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
 by mailman.nyi.freebsd.org (Postfix) with ESMTP id B51D113E9A0
 for <freebsd-arch@mailman.nyi.freebsd.org>;
 Sat,  5 Oct 2019 22:50:38 +0000 (UTC) (envelope-from ian@freebsd.org)
Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org
 [54.186.57.195])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 server-signature RSA-PSS (4096 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 46m25V0xMgz4DDn
 for <freebsd-arch@freebsd.org>; Sat,  5 Oct 2019 22:50:37 +0000 (UTC)
 (envelope-from ian@freebsd.org)
ARC-Seal: i=1; a=rsa-sha256; t=1570315836; cv=none;
 d=outbound.mailhop.org; s=arc-outbound20181012;
 b=L6fkPqz3COyWs6y0Ha1DLAiJqiP48+thEbPWukrWH1dLgtxOI9xRDY4eMTsGi6nPOlObd5MBYqk5M
 gEg5tD+YiSQWpplrmonxsbOqtMqaNyM26BwS0U/olpZqudxBHkUAc07f9kBeL4l+dA1BoxX6B6kQXv
 gi2Y9FX3A5dbG1opurXLnBUhDkJc5upjNMbL98BH9c1oCtYAIBwhLpsjECV/yYNZvgqUe1DgfuWJ77
 nRG1Zt9acPBDQyzW6mNQQkNuSe6g/E/kCERcm3yxFBjDfzY3h2x+GDAPIXcnKcNsLInrmriTzfNZxy
 2vrXjf28IVfHYU/jmfHD/QaEnpR+MaQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
 d=outbound.mailhop.org; s=arc-outbound20181012;
 h=content-transfer-encoding:mime-version:content-type:references:in-reply-to:
 date:to:from:subject:message-id:dkim-signature:from;
 bh=9XtkUVKsPlMwl+oOmEOHQSRn02jPyXs7RhEDFwPnPF8=;
 b=BOMWbChfJAa1EIrCE6zvI1ag5bnjKFi32Irrf9IPWnswSNj7ULKuhuMeGvHWCSz9je0NTPqh46SnD
 fF/ZIu4+Q5Eb+Zgnp0cWX1xaVryuqO+/IVTGSO0YmXWV7GyjTsMKsebzVVqGWbXHcvaREg55dbyqlf
 E9phUSAfXOV9EYwsISrqHrc2Th+CRybcJ8bRXLpvtQzJ5bnJJNNRnr2TuVta8atSF6ZRqWMMi/ZXJu
 ExbqNxAz21/C60lr8Ifb30EgYDEDl32O4n5QAeIDLFNeWGSManQrWRdmtg1sIuWwwRMKPMebDa0/R5
 KeSwUjxgPIer2YFoRKdnZgMmYK2zhdA==
ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org;
 spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60;
 dmarc=none header.from=freebsd.org;
 arc=none header.oldest-pass=0;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=outbound.mailhop.org; s=dkim-high;
 h=content-transfer-encoding:mime-version:content-type:references:in-reply-to:
 date:to:from:subject:message-id:from;
 bh=9XtkUVKsPlMwl+oOmEOHQSRn02jPyXs7RhEDFwPnPF8=;
 b=FdZZlZvclcrExB4f7V3yYN8N+Rqy74UzlX6SAx7/3KGlfIRbAyFfqddiI929PxHsBLMVdxlEAJcra
 DN+XL/8jaslKWLbwy/IaCMRR7vYAC8jFgT9+iuif+zKAVu1lpD261GKQ0gAKtu5ySfTggFpJNmE8Pj
 ZQbmwuOMkTSbge4kA97yJqP2rNThnhXE078c3Eb+Xw8XFJ0VlfjayBnS3x97zakuijJagvrvfRQ4mo
 5L6Vy1n7PQ15D2oELiSKY5aGvSzu9grMGRjoSN1QBC5bpY7f+k1BJi2VucGqhPoJjwQQinwXTQLRjS
 JNN9U9X9UzHsINK5NnsBZQ6E9XpsytQ==
X-MHO-RoutePath: aGlwcGll
X-MHO-User: 8953bd45-e7c2-11e9-955f-dfabc1efb494
X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information
X-Originating-IP: 67.177.211.60
X-Mail-Handler: DuoCircle Outbound SMTP
Received: from ilsoft.org (unknown [67.177.211.60])
 by outbound3.ore.mailhop.org (Halon) with ESMTPSA
 id 8953bd45-e7c2-11e9-955f-dfabc1efb494;
 Sat, 05 Oct 2019 22:50:34 +0000 (UTC)
Received: from rev (rev [172.22.42.240])
 by ilsoft.org (8.15.2/8.15.2) with ESMTP id x95MoWM5072982;
 Sat, 5 Oct 2019 16:50:32 -0600 (MDT) (envelope-from ian@freebsd.org)
Message-ID: <20f9896361c341736c5154c010cedf3fdcffc235.camel@freebsd.org>
Subject: Re: New CPUTYPE default for i386 port
From: Ian Lepore <ian@freebsd.org>
To: Cy Schubert <Cy.schubert@cschubert.com>, freebsd-arch@freebsd.org,
 Warner Losh <imp@bsdimp.com>, Shawn Webb <shawn.webb@hardenedbsd.org>
Date: Sat, 05 Oct 2019 16:50:32 -0600
In-Reply-To: <06E29438-732D-4045-8FB3-5F2A082E9B98@cschubert.com>
References: <CANCZdfoFPsjyuCTfm0dQhz+sgVHLEvMA8-E3-Yhciz67qdoKvw@mail.gmail.com>
 <20191005173411.l6gs3kszs7zcgfey@mutt-hbsd>
 <CANCZdfo6=r7BaGA8qKYSR9ba=azzxD+yDkN4aO87Oj1Qr9TKmA@mail.gmail.com>
 <06E29438-732D-4045-8FB3-5F2A082E9B98@cschubert.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 46m25V0xMgz4DDn
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	none
X-Spamd-Result: default: False [-1.97 / 15.00];
 local_wl_from(0.00)[freebsd.org];
 NEURAL_HAM_MEDIUM(-0.97)[-0.966,0];
 ASN(0.00)[asn:16509, ipnet:54.186.0.0/15, country:US];
 NEURAL_HAM_LONG(-1.00)[-1.000,0]
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>;
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Oct 2019 22:50:38 -0000

On Sat, 2019-10-05 at 14:20 -0700, Cy Schubert wrote:
> On October 5, 2019 11:19:41 AM PDT, Warner Losh <imp@bsdimp.com>
> wrote:
> > On Sat, Oct 5, 2019, 11:34 AM Shawn Webb <
> > shawn.webb@hardenedbsd.org>
> > wrote:
> > 
> > > On Sat, Oct 05, 2019 at 09:28:53AM -0600, Warner Losh wrote:
> > > > 
[...]
> > > I'm curious about the possibilities regarding 64-bit time_t on
> > > 32-bit
> > > Intel systems.
> > > 
> > 
> > Beyond the scope of this discussion. However, feel free to start a
> > thread on this. It's quite difficult to switch if you want binary
> > compat. It would affect system calls on the upgrade path and is
> > among the hardest types to change if you have any kind of legacy to
> > support...
> > 
> > Warner
> > 
> > 
> 
> This is one of the two reasons I believe we should deprecate 32-bit.
> Even supporting 32-bit compatibility long term is unsustainable. It
> is not worth the effort.
> 
> Putting a stake in the ground to say we no longer support 32-bit
> after 2038 would be desirable. (Sooner the better though.)
> 
> 

Only i386 has a 32-bit time_t.  Other 32-bit arches either began life
with 64-bit time_t or have been switched to it.

For i386, if its current users (and I am one, for $work) have a choice
between "As of date X there will be no more i386" and "As of date X we
switch time_t to 64 bits and you will not be able to run old binaries
after that" I suspect people would choose the latter.

-- Ian




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?06E29438-732D-4045-8FB3-5F2A082E9B98>