On Fri, 2018-01-05 at 10:37 +0200, Graham Leggett wrote: > On 04 Jan 2018, at 2:09 AM, William Brown <wibrown@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o > rg -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
