I've been held up by my work, but here is the continuation of the conversation regarding i586 CentOS-5:

On 01/11/2010 08:18 PM, Karanbir Singh wrote:

...

  * Can the changes mentioned in that article be incorporated into the
    stock SRPM?  (As far as I know, non-i586 builds should not be
    affected)

No, but there is a big open door in the c5plus kernel window. That would be the best place for this.

However, expanding a bit ( and this conversation might be better for -devel rather than -docs ).

Is the modified kernel the the only bit of change you need for i586 support ? I'd think a glibc.i586 might be worth doing as well. And there were a few other packages that were required to be patched on c4 to make it work for i586. How many of those are needed here as well ? And there are a lot of patches in the kernel tree that might not impact the i586 code at all. eg. whats the state of xen in this i586 kernel ?

For my purpose, yes. The modified kernel and glibc.i386 and openssl.i386 are all I needed to get the system running from CF card. I'm not using the procps RPM, but using busybox instead.

I never tested Xen support on the i586 kernel.

The "CentOS5PentiumSupport" wiki doc mentioned that "-ffast-math" generated CMOV instructions in .i386 packages. That sounds more like a gcc bug. So instead of patching all the packages that enable "-ffast-math", patching gcc would be the ultimate solution.

If there is reasonable interest in running a i586 tree, then imho, a SIG dedicated to this would be the best route to go. It would also make it possible to have a i586 specific tree that can be maintained in parallel to the main core distro.

I can see that the amount of physical hardware available for testing i586 packages is limited, but I guess when CentOS-4 reaches EOL, some people might opt for a CentOS-5 upgrade path.

Anyway, I'm happy to help out with any testing on physical hardware. When I do find the time, I'll try to look into the CMOV and gcc issue, but no promises there. One thing I'm not good at is organizing things, so I won't volunteer to initiate the SIG...

Regards, Timothy Lee