On Fri, 2018-01-05 at 10:37 +0200, Graham Leggett wrote:
On 04 Jan 2018, at 2:09 AM, William Brown <wibrown(a)redhat.com>
wrote:
> We have begun the process to remove i686 support from the server.
> You
> should plan that all 1.4.x builds will support 64bit platforms
> only.
>
>
https://pagure.io/389-ds-base/issue/49514
>
> We recommend that you move to a 64bit platform (x86_64, aarch64,
> ppc64le) which we support.
Can you clarify the justification for this. What happens if you want
to run 389ds on an embedded low power 32 bit device?
For about 6 months an issue in the way that 389ds has managed 64bit
atomics has been able to cause data corruption and server crashes.
In libc there are a number of __atomic_* types that promise that "They
perform atomic manipulations of the data, falling back to a mutex in
the case that a native cpu atomic can not be used". On 32bit platforms
this fallback does *not* occur correctly, meaning that either the lower
or upper half only is atomically updated. This is due to variable
alignment not being correctly emited by gcc, meaning we would have to
then align every data that uses this.
This was discovered due to expansion of our testing capability of the C
code base - a server stress test showed that counters could become
wildly inaccurate.
Given we use atomics for reference counting in a number of objects, as
well as for monitors, this can cause objects to leak, be freed early,
or to report incorrect data,
Because this issue had been present for so long we reason that:
* There are almost no users of the i686 platform
* People aren't noticing the issues
Given that we want to offer the best directory server possible we made
a decision about our time - do we invest the time to correct this
defect? Or do we move our support bar away?
We decided to move the support away. It's easier on us support wise
(none of us own 32bit hardware to develop on) and we would rather
invest our time in improving the server for the majority case - 64bit
users. 64bit data types are today faster for a native 64bit cpu to
handle, and far more scalable. The majority of our users are on x86_64
platforms, so we want to invest there - while keeping the door open to
things like aarch64 and others.
I did consider the "small install" situation, with people who might be
running ds on small arm boards like raspi. If I recall correctly, raspi
model 3 is 64bit capable, as are many other embedded boards today.
Additionally, lower power systems like alix boards and nuc are all
64bit. There are many options available now in this space that are "not
32bit".
I hope this helps to explain our decision, and I'm sorry if it will
cause you inconvenience :(
Regards,
Graham
—
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.o
rg
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane