From owner-svn-src-head@freebsd.org Sat Nov 18 22:53:47 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7DB2DDEA1E; Sat, 18 Nov 2017 22:53:47 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 978B580B3B; Sat, 18 Nov 2017 22:53:47 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 6822C5A9F27; Sat, 18 Nov 2017 22:53:40 +0000 (UTC) Date: Sat, 18 Nov 2017 22:53:40 +0000 From: Brooks Davis To: Stefan Esser Cc: Pedro Giffuni , Stefan Esser , src-committers , "svn-src-all@freebsd.org" , rgrimes@freebsd.org, "svn-src-head@freebsd.org" , "O. Hartmann" , Warner Losh Subject: Re: svn commit: r325954 - in head: . share/mk sys/conf usr.sbin/config Message-ID: <20171118225340.GF35747@spindle.one-eyed-alien.net> References: <201711180134.vAI1Y2ks064138@pdx.rh.CN85.dnsmgr.net> <29499AF9-FC0A-4CDA-9657-B092B3F9A0D0@FreeBSD.org> <04747a89-4dc7-a476-dc32-a158ee1f5240@freebsd.org> <75597b23-7a8c-34ad-736b-8d68ce7dea06@FreeBSD.org> <0186512e-dc90-6d00-c048-d87a9c1948a3@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mvpLiMfbWzRoNl4x" Content-Disposition: inline In-Reply-To: <0186512e-dc90-6d00-c048-d87a9c1948a3@freebsd.org> User-Agent: Mutt/1.9.1 (2017-09-22) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2017 22:53:48 -0000 --mvpLiMfbWzRoNl4x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 18, 2017 at 05:14:28PM +0100, Stefan Esser wrote: > Am 18.11.17 um 16:01 schrieb Pedro Giffuni: > > Hi; > >=20 > > On 11/18/17 09:15, Stefan Esser wrote: > >> Am 18.11.17 um 03:31 schrieb Pedro Giffuni: > >>>> On Nov 17, 2017, at 20:34, Rodney W. Grimes > >>>> wrote: > >>>> > >>>> [ Charset UTF-8 unsupported, converting... ] > >>>>> Kib@ posted to arch that we were removing it, nobody objected, we r= emoved > >>>>> it. If it was a working feature that might have a few users, that's= one > >>>>> thing. But I don't think make lint has actually worked in at least = a decade. > >>>> Thats a sad state of affairs. > >>>> > >>> t?s not sad, just the way things are, modern compilers are doing much= of > >>> the checking older tools like lint used to do.. OpenBSD and Dragonfly= BSD > >>> both killed lint ages ago. > >>> > >>> OTOH, we should probably consider other tools, like sparse: > >>> > >>> https://sparse.wiki.kernel.org/index.php/Main_Page > >>> ? The license is fine and it plays nice with the compiler. > >> It builds on -CURRENT, but the Makefile needs some tweaks (it does > >> not find LLVM or Gtk+-2.0, even though they are present on my system). > >> > >> I'll work on a port over the weekend ... > >=20 > > Thanks! >=20 > I've got a port that builds all of sparse except sparse-llvm. The sources > use GNU extensions, and I do not think it is worth the effort to provide > standard compliant replacements for them at this time. >=20 > Building sparc?se-llvm will take some more effort and require the LLVM po= rt > to be installed, since it references headers not installed by our system > compiler. It is an optional component, but one we definitely should have. >=20 > I'm not sure how to proceed, but the easiest path forward is to make the > LLVM support optional and depend on one particular LLVM version (i.e. 4.0 > for now) built from a port if the option is enabled. >=20 > > For it to be really useful we still would have to add annotations to the > > kernel headers. >=20 > Well, those could be added over time ... >=20 > > I just resurrected a recent proposal from brooks@ into the IdeasPage: > >=20 > > https://wiki.freebsd.org/IdeasPage#Userspace_Address_Space_Annotation > >=20 > > It is actually a fun project but my hands are full! >=20 > The port was easy, so far, I'll commit it without sparse-llvm for now. > LLVM support will follow when I've got the remaining build issues resolve= d. I wrote up a port a month or so ago, but I didn't commit it because I belive they authors of sparse failed to understand how C qualifiers work and the __user annotations used in linux are harmful as a result. The problem is that they annotate the data not the pointer. You can make a case for this for the address space annotations, but I believe it's completely wrong for the anti-derefernce guards. I'd hoped that that the linux style __user annotations would be a good match for the __capability annotations we use in CHERI to denote pointers that are capabilities (fat pointers), but they aren't usable. This makes me sad, but I will object to adding these annotations to our tree. (Some of the other annotations look ok, but I've not tested further after this disappointment.) -- Brooks --mvpLiMfbWzRoNl4x Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJaELnzAAoJEKzQXbSebgfApUEH+gOQvsni0/Hv9UbqcmiK1rp2 ZHmu7iFXQknqrnz9z9DeLWvo7tNJYqEU4TyKVbAgJ+lytXVltZ0p/HZWVNpJtwD4 V8a9ueKXicixEDhEu9BDZxr/6muG4HEFX1lfUaxjBhBmcsenQJcZCSvxGxwdjw5x VDnKuf2mlo+SFm7eHUsq/i8xops+mBxmwzbulmYch044Pj/IdcRkMk4srp8D3siT zO+P+9FaxFivGPv+7bIxokVPTT7D1qlxZUz84zmhymeM2xt8uG11tLBssI2/eUGy +TP2fCwy0yNn8Z8o37xWeHw+RGhpfdSMx0w7ROym3tQ7uOcwSEIy7q+VscSkgPQ= =bfAk -----END PGP SIGNATURE----- --mvpLiMfbWzRoNl4x--