i386 and x86_64: back together?

Posted Jul 31, 2007 21:38 UTC (Tue) by iabervon (subscriber, #722)
Parent article: i386 and x86_64: back together?

If IDE/SATA is the ideal model, it's worth noting that, while "IDE" is going away, it's partially being replaced with "PATA" which is a different name for the same thing, but is the name under which libata supports it. And, aside from exceptionally lost devices, libata is getting support for all of the old IDE devices (as well as new devices; optical drives still seem to be routinely PATA, even when the hard drives are SATA).

This would suggest that the correct thing to do is to rename x86_64 to x86, make it not use files out of i386 and add support for 32-bit processors to it, starting with non-quirky ones and progressively filling in weirder stuff in ways that doesn't impact the regular code. Then i386 is made obsolete when x86 handles everything. This would probably take some time, but probably not any longer than PATA, which seems to be coming along, and the switch will be easier on users (since they won't have their root partition device's major and minor change on them in the process).

i386 and x86_64: back together?

Posted Aug 1, 2007 4:14 UTC (Wed) by wilreichert (guest, #17680) [Link]

I was thinking a similar thing, tho oss -> alsa was the first thing that came to mind for me. Think the heathrow controller on my Mac G3 is one of the few drivers left to be ported to libata.

i386 and x86_64: back together?

Posted Aug 1, 2007 6:04 UTC (Wed) by arjan (subscriber, #36785) [Link]

there is a difference though.. the ide code was old and crufty and barely alive (although Bart did and the people before him did a good job to keep it breathing).

both i386 and x86_64 are in a relatively good shape, so picking one isn't per se the right move; the proposed method allows for picking the best of either worlds on a per component basis. Sometimes x86_64 is better (for example around change_page_attr() code), sometimes i386 is better (timer/event handling as used by tickless).

For ide/libata-pata it would be an extremely one-sided deal, not worth it. For this one.... it also allows for a much more gradual change, with each step bisectable, testable and debuggable (something the ide->libata move isn't either; for good reason since the starting point would have been nasty).