svn commit: r251796 - head/sbin/hastd

[Pawel Jakub Dawidek]

On Sun, Jun 16, 2013 at 11:42:21AM +0200, Ed Schouten wrote:
> Hello Pawel,
> 
> 2013/6/16 Pawel Jakub Dawidek <pjd at 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?
> 
> 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:
> 
> http://svnweb.freebsd.org/base/head/sys/sys/stdatomic.h?r1=251347&r2=251566
> http://svnweb.freebsd.org/base/head/sys/sys/stdatomic.h?r1=250883&r2=251192
> http://svnweb.freebsd.org/base/head/sys/sys/stdatomic.h?r1=228862&r2=228880
> 
> 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.
> 
> 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.
> 
> 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.

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://mobter.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20130618/e5286d38/attachment.sig>