LWN: Comments on "i386 and x86_64: back together?"

i386 and x86_64: back together?

jackb — 2007-10-14T02:57:39+00:00

How does this affect users at all beyond the code quality issues that the developers also care about?

It's not like the issue is visible from userspace.

When I install a new kernel version, all my machines will use the same file name for the image:

/usr/src/linux/arch/x86/boot/bzImage

Not very signifigant, I agree, but still a userspace-visible change.

i386 and x86_64: back together?

k8to — 2007-09-10T04:42:12+00:00

How does this affect users at all beyond the code quality issues that the developers also care about?

It's not like the issue is visible from userspace.

i386 and x86_64: back together?

jzbiciak — 2007-08-07T14:28:57+00:00

It sounds like it's both: It's probably more short term pain for more long term advantage.

i386 and x86_64: back together?

proski — 2007-08-02T19:44:44+00:00

The whole point of merging is to make it less pain for the developers.

i386 and x86_64: back together?

jpick — 2007-08-02T16:31:34+00:00

Merge'em. It may be more pain for the developers, but this affects millions of users.

i386 and x86_64: back together?

arjan — 2007-08-01T06:04:30+00:00

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).

i386 and x86_64: back together?

wilreichert — 2007-08-01T04:14:08+00:00

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?

iabervon — 2007-07-31T21:38:38+00:00

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).

overriding the maintainer...

firasha — 2007-07-31T19:45:38+00:00

Conceptually, I love this patch. It's easy to see why a lot of other maintainers like it. So it may seem strange that Andi opposes it. Going back in history, Andi has almost always objected to x86 (-32 or -64) patches that he believed would result in the archs requiring more effort to maintain--which seems a perfectly reasonable attitude, yes? In this case, he clearly feels the "old cruft" will make it harder to keep the x86-64 codebase "pure". In fact, independent of anything else, he really wants to get rid of NUMAQ/Voyager/P5-SMP/visws support, saying "those [users] could continue using old kernels".

Now, it's not new to see the tired old "legacy users should use legacy kernels" argument trotted out again. Anyone who has followed lkml for awhile knows that over the years, Linus and others have repeatedly, and vehemently, shot it down every time it comes up. Usually, though, it's brought up by a newbie posting to lkml; I don't remember the last time a major maintainer argued for this, and it frankly worries me.

I love the fact that Linux is willing to support just about any hardware or filesystem. Indeed, over the years many maintainers have stated that adding all the weird stuff forces them to think outside the box and come up with better abstractions, and that the end result is in fact code that is better designed, more elegant (and sometimes actually more performant) than if the code were excised of all that "legacy cruft".

When support for a feature *is* removed, it's almost always because it's started to bitrot, and nobody is willing to step up and resurrect it--but there's always the possibility of bringing it back sometime in the future (see the thread about removing the arm26 port for a recent example).

In the end, I think it comes down to what the role of a maintainer is. Andi, on dealing with the potential difficulties of the arch merge: "I must admit I prefer hacking on new code instead". The higher up the maintainership ladder you go, though, the less time there is for lots of personal hacking. Linus and Andrew are primarily patch integrators at this point; they don't have the time to engage in major personal hacking any more. Most of the major subsystem maintainers are similar (although they do have more time than Linus or Andrew, and they do still get some of their own hacking in). So avoiding the stickier problems in one's maintainership bailiwick because of a preference to hack, while understandable, isn't really the maintainer's job.

Andi has also recently been taken to task several times for questionable code or decisions--it's been most noticeable to me over the last six months or so, but you can see indications in posts even further back. The most recent I can recall at the moment is the breakage caused by commit 19d36ccdc34f5ed444f8a6af0cbfdb6790eb1177, which Linus commented upon thusly:

I think it shows a total lack of taste and understanding, and I'm totally tired of it. This has happened too many times.
Andi: please don't send this patch *ever* again.

Personally, I think Andi is a gifted hacker. I have no complaints there. But I have to wonder if the maintainer's robes are still comfortable for him. He seems to chafe at some of the responsibilities that are expected of maintainers, and this does seem to have lead to some less than optimal decisions. It may be that he would be a more valuable contributor--and personally happier--if he handed the responsibility to someone else. Unfortunately, maintaining x86 is not at all easy, and there are very few qualified for the position. It's a difficult problem.