Date: Tue, 18 Jun 2013 10:29:08 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Ed Schouten <ed@80386.nl> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r251796 - head/sbin/hastd Message-ID: <20130618082907.GA1368@garage.freebsd.pl> In-Reply-To: <CAJOYFBDKhHE9dMk81kYPNRp4PJYEVtrfzZSMfchuwdGMofD3eQ@mail.gmail.com> References: <201306152218.r5FMI0uT047135@svn.freebsd.org> <20130615232314.GB1403@garage.freebsd.pl> <CAJOYFBDKhHE9dMk81kYPNRp4PJYEVtrfzZSMfchuwdGMofD3eQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 16, 2013 at 11:42:21AM +0200, Ed Schouten wrote: > Hello Pawel, >=20 > 2013/6/16 Pawel Jakub Dawidek <pjd@freebsd.org>: > > Hmm, I don't like HAST to be a victim of bad LLVM import. This is not > > the kind of software you run on HEAD (so it might go unnoticed > > initially) and this is the kind of software that when breaks can have > > serious consequences. > > > > What kind of breaks are we talking about? That HAST will stop compiling > > or HAST can start corrupting data? >=20 > My intent is that we shouldn't see a whole lot of C11 atomics in > FreeBSD appear before we have at least one stable branch that supports > it properly (10.0). The problem with this approach is that I've > noticed that if we import things into our base system that we hardly > use, it will get almost no coverage. This causes all sorts of breakage > that could have prevented easily. Good examples: >=20 > http://svnweb.freebsd.org/base/head/sys/sys/stdatomic.h?r1=3D251347&r2=3D= 251566 > http://svnweb.freebsd.org/base/head/sys/sys/stdatomic.h?r1=3D250883&r2=3D= 251192 > http://svnweb.freebsd.org/base/head/sys/sys/stdatomic.h?r1=3D228862&r2=3D= 228880 >=20 > By at least letting a couple of pieces of code use C11, this is less > likely to regress again. The examples that I gave of course refer to > breakage of <stdatomic.h>, not regressions in LLVM itself. I merely > named regressions in LLVM as a worst-case example. My assumption would > be that any breakage in LLVM related to C11 atomics is as likely as > any other kind of regression. >=20 > If you want, I can revert this change. Still, I would actually prefer > it if we not only let HAST use C11 atomics, but also a small number of > other pieces of code. That way any kind of breakage would become > pretty visible. >=20 > Thoughts? Your commit message suggested that HAST is the only consumer of C11 atomics or at least part of very small group. I have two concerns: 1. HAST doesn't have many users and HAST users most likely don't run HEAD, so HAST is really bad place to expose problems. Compare it to using C11 atomics within libc or libutil. 2. Breaking HAST can corrupt people's data, which is always bad, but in HAST case it is even worse, because if you run HAST you care about your data and your service very much (why would you need cluster setup if not?) That's why I asked of types of breakages do you expect. If the breakage that can happen is compilation error then this is fine, but if the breakage can be a race condition in HAST which can lead to data corruption and/or unreliable service then this is not fine. If the latter is possible then yes, I'd like this to be backed out until we grow more C11 atomics consumers in the base code that have a chance to expose bugs in HEAD, like some core libraries. I hope you understand my concerns. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHAGlMACgkQForvXbEpPzQWjQCfYLqbOiamkkxXEw1wV8FZQ07i oC4An3emdxgDU68TlBCVRBsa0wW8cZhb =8vs9 -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130618082907.GA1368>