[CentOS-devel] [CentOS-docs] Article on building i586 CentOS-5 kernel

[Timothy Lee]

  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