Slashdot Mirror
The Silent Kernel Platform War?
iJosh asks: "Recently I decided to be hip and cool and update to the latest Linux Kernel (v2.4.1). Since this decision I've downloaded and tried to compile the offical source from Linus and crew on my PowerMac 7300 only to run into errors for the PowerMac PCI controller. I took this up with Paul Mackerras maintainer of the PPC kernel and his response was quite interesting to say the least and it got me thinking. He basically says that Linus is ignoring the patches from the people working on the PPC side of the kernel, and that they are keeping their own tree so people are not stranded out in the dust with kernels that will not work. My question really comes down to this: Is the linux kernel forking away from PowerPPC? Is this happening because of issues regarding OS X and the possibility of many users jumping ship, away from LinuxPPC upon release? Or is this some kind of quiet platform war from the major kernel developers?"
As someone who actually works on the PPC kernel, I do admit that there are bugs, but the other side of the coin is that hardly anyone reports these things. The developers only have a finite number of machines, and can only test what they have.
But anyways, frambuffers are working well (with an occasional problem on the wierder ATIs, or some of the undocumented apple controllers.) Serial was broken once upon a time, but that's been fixed for ages (and even made it into Linus' tree in 2.4.2pre2). I assume you're referring to "standard" IDE cards which work in 2.4. Patches do indeed get ignored, but again there's more people trying to keep track of things now.
As for the rewrites you mention, I know some of the recent ones have been so that new machines can be used and maintained sanely.
Unfortunately, it has sat in "ready Real Soon Now" status for a long time now. I'd hazard the guess that a bunch of developers are feeling rebellious about the fact that it is not free software.
By the way, the "let's set up a CVS repository" idea has the conspicuous demerit at "send the patch to Linus time" that it is still going to take a lot of effort to make sure that the patches that get sent on to Linus are reasonably perspicuous. You're still left with the dilemma that:
But this will tend to "bulk up" into something that involves a horde of changes, which again will not be terribly perspicuous.
This is certainly spelled "dilemma," as all the alternatives are pretty poor...
If you're not part of the solution, you're part of the precipitate.
Not in this particular case. It's being rejected due to the sheer size of the patch required. It's a fairly significant change, and, well, Linux ain't to hot on updates such as those. Alan Cox is the only reason why alot of the stuff makes it into the kernel..
-- I'm the root of all that's evil, but you can call me cookie..
I think a lot of people are _greatly_ misinformed about Linux forking. The truth is, there are at least tens of forks of Linux. Every major distribution has it's own kernel tree - no major distribution has ever shipped one of Linus's kernels. They all have at least one patch or another applied on them. Then there are projects like ucLinux, which are pretty major Linux forks. And then you have the real-time Linux forks, of which there are several. So, the LinuxPPC forking is really not a new thing. Linus is generally pretty slow about applying patches for other architectures. If you are not on an x86 box, you _need_ to not be running a Linus kernel - you almost have to run a forked version. It's not that Linus doesn't like the other architectures or that the other architectures are trying to be rebels. They just have different goals and emphases. Linus can't validate every patch that comes in for every architecture, so he generally just does the x86 stuff. Also, Linus doesn't like large patches, because he can't validate them. And the patches for other architectures tend to be large. Anyway, kernel forking is a regular part of Linux, it's been happening for years with no ill effects (all the good stuff from each fork is shared). In fact, it's rather positive.
Engineering and the Ultimate
When Linus can start delegating authority over subsystems, when Linus can learn to use revision control, when any kind of coordination of changes affecting multiple subsystems does or even *can* go through anyone but Linus himself, then perhaps he won't need to personally review each and every patch that comes to him.
As it is now, he doesn't even trust Alan Cox to maintain any part of the official tree -- he still has to send Linus patches. Forks do happen in a project, when such sweeping changes are needed, and they get merged in later versions. Linus tacitly admits this because he can find an incremental way to do it each time. In other cases, people decided to just stop trying to go through Linus, because they know what Linus doesn't: Linus doesn't know everything.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
That makes the forking, what, 2 1/2 years old?
Yeah, it re-integrates from time to time, but the official kernel tree hasn't been the place to get a *usable* PowerPC kernel in like forever.
PS - don't get me started on support for weird PowerPC chipsets. Just don't.
_Deirdre
Actually, at a MacWorld one year (1995?), IBM was showing Windows NT running on an IBM CHRP-based PowerPC system.
The project was axed.
_Deirdre
> if MS ignore a set of hardware, they lose money, so they won't do it
So where is Windows for PPC?
-- Don't Tase me, bro!
The same complaint goes for m68K (which has maybe a handfull of mainstream kernels that even compile) and quite often for (u)sparc. There are lots of conspiracy theories but I think that the answer is very simple: endian-ness. Let's face it most linux development is done on 32 bit little endian. And quite a lot of people do not recheck their stuff for endian issues.
Hopefully now, with IBM's and other "big endian guns" involvment the issues will subside by themselves.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
Similarly, the sparc tree's most up-to-date stuff can be found at the repository David S Miller maintains on vger.
In addition to being the gatekeeper for the official tree, Linus is pulling double duty as the portmaster for the x86 port. Thus, the x86 stuff is always up-to-date in the official tree, and the other archs tend to have some lag time associated with them.
This is nothing new. It's just symptomatic of the hierarchical Linux development style. {Free|Net|Open}BSD don't tend to suffer from this due to their use of a central CVS repository with all portmasters having access to their relevant parts. Whether this is a better system is left for others to flamewar about, but it does prevent the port floating the author is talking about.
This is exactly why Linus wants small patches. With a small patch, it is possible to quickly look at it, see what it's doing, and evaluate the patch on several levels:
clarity - is it clear what the patch fixes/adds (this tends to be a sign of well-written code)
correctness - a 300K patch would take days to go through and make sure that you aren't breaking something else by applying the patch. Small gotchas will stand out more in smaller patches.
If you apply a 300K patch, and something new breaks, what do you do now? Look through the code slowly and try to figure out what happened. With a small patch, there is a greater chance that you can back out exactly what change broke whatever function, making it easier to find where you broke it, if not why.
Doug
Venn ist das nurnstuck git und Slotermeyer? Ya! Beigerhund das oder die Flipperwaldt gersput!
http://kt.linuxcare.com/kernel-traffic/kt20010108_ 101.epl#7, http://kt.linuxcare.com/kernel-traffic/kt20001127_ 95.epl#6
and especially: http://kt.linuxcare.com/kernel-traffic/kt20001002_ 87.epl#3, http://kt.linuxcare.com/kernel-traffic/kt20001010_ 88.epl#7.
Have a good read. KernelTraffic Rocks.
-Chris
http://www.nondot.org/~sabre/os/
So, if your small patch is "Prevents the Frangle Hyperqueue Monitor from crashing on PPC", how does it get verified in the official kernel if you need 50 other similar small patches before your kernel will even get as far as trying to access the Frangle Hyperqueue on PPC?
Quattuor res in hoc mundo sanctae sunt: libri, liberi, libertas et liberalitas.
Really...
The LinuxPPC kernel (that's all I can speak about aside from the x86 kernel.. no experience with the others) and the main distribution tree have always diverted away from one another, and, then, seemingly magically, they get sync'ed.
If I remember correctly, it wasn't until the 2.1.128 series kernel that it started building, right out of the box (http://www.kernel.org) on a PPC box. Prior to that, PPC users had to rsync their kernl from a site in AU.
From then on through the 2.2 kernel, this remained true. But, as new Mac hardware flooded into the pool and USB device support became a much higher demand, patches and changes to the kernel came at an accelerated rate, and the master kernel source (http://www.kernel.org) didn't provide the functionality PPC users wanted/needed.
With the 2.4 kernel, it seems that almost all support within the master kernel tree has been halted, and, hence, secondary architecture-focused trees have popped up to fill the void.
PPC users have gotten accustomed to the kernel.org kernel source working for them (as it does for most other architectures), and, with that comes a feeling of acceptance. The fact that it hasn't been working as of late seems like a step backwards (or, in this case, sideways), and is pretty disappointing..
I suspect that, as one response stated already, things will get sync'ed again as soon as it bubbles up to the top of Linus' to-do list.
Zeros, Ones, and sometimes Twos.
I could kick my own ass for thinking different.
Don't post on slashdot anymore pal. This site is for people with brains in their heads, not prejudism in their heart.
You must be new...
--
I'd hope that architecture politics stay away from the linux kernel.
Chris Kuivenhoven is a thief, beware
Yup, go read the linux-kernel mailing list archives; at least once every couple of months, someone tries to give Linus a 300K patch, and he rejects it. Linus wants *small* patches, which do specific things, or implement one new feature.
Kernel Traffic has summarized this numerous times, if you don't want to wade through the lkml. Essentially, the only reason NON-platform-specific stuff gets through faster is because it all goes to Alan Cox, who then stuffs them into his own tree (the -ac* patches). When he decides they're stable enough to pass on, he breaks them up into bite-sized pieces for Linus.
It sounds like the PPC maintainer isn't willing to do this, and so they're falling by the wayside.
1st Law Of Networking: Loose ends are bad, termination is good.
WWJD? JWRTFM!!!
He can choose to:
- Take the PPC patches as gospel, and throw away everyone else's contributions,
- Go through a whole lot of work breaking the PPC patches down into bite-sized components, or
- Tell the PPC developers to turn the PPC patches into bite-sized components themselves, and ignore the huge patches that he hasn't time to integrate in.
In effect, he's going with "option 3" here, and that's not an outrageous outcome. The LinuxPPC folk may not like this outcome, but it's neither new, capricious, nor is it discriminatory. Alpha has suffered from much the same issue...If you're not part of the solution, you're part of the precipitate.
Well, I won't even try to rely to most of the crap I've read here, sorry guys, but some of your comments are just so...
;) The truth is that we are in fact paid by Microsoft to write crappy code, flood Linus with huge and unmergeable patches in the clear intend to cause a Linux fork !
There are several points about the PPC arch. First of all, it's huge and very quickly growing. Why ? Well, in a single arch, it handles all PCI PowerMacs (with new hardware coming out of Apple every 6 monthes), CHRP boxes (including some RS6k IBM machines), PReP boxes, APUS, NuBus PowerMac is coming in, Gemini, and I'm forgetting some...
Add to that the embedded hardware (8xx CPUs, 4xx CPUs coming in soon) with the zillion of hardware variations.
So it's _huge_, it's quickly moving forward (remember USB, we needed to get that working for kbd and mouse on iMacs while most x86 boxes didn't even had Windoze drivers for their USB controller), and the necessary consequence is that patches are huge. Fortunately, most of them just touch arch/ppc, include/asm-ppc or PPC specific drivers.
But I'm not telling you all here
Ben.
I hate to be an old.fart.kernel.hacker and rain on your parade, but there is no news here. Stuff like this has been going on since 1995, at least, with all of the non-ia32 ports. It's a pretty simple problem - Linux supports a lot of platforms, and platform developers don't usually synchronize well with Linus's attempts at keeping some sort of release schedule for the "core" kernel. Linus himself worked on the initial AXP port, and it wasn't long before it fell off the "core" radar and had a separate team with independent patches feeding it. It wasn't a fork, it was just a concession to practical limits on Linus's time and energy.
IIRC, Linus' usual behavior with platforms he doesn't frequently use is to let the primary maintainers feed him big merges periodically... he basically lets them run their own "development" cycles (the "odd" cycles for the core kernel) and merge "stable points".
Since we're now in 2.4.small# mode, Linus is going to be extremely anal retentive about what he accepts, at least until 2.5 launches. I don't know the nature of the stuff the PPC people may be trying to feed him right now, but odds are unless it's either a critical bugfix or an "independent merge" that's been long planned for (f.e. reiserfs), it'll be rejected. When we get into later 2.4.X's, the policy will probably become more liberal.
The rule has always been (ever since the Alpha and M68k ports) that if you run on an alternative platform and follow the latest greatest developments for that platform, track with its maintainers kernels, not with the "mainstream". If you want to follow latest-greatest core stuff, either use ia32 or use a known-good arch bundle and cross-port any necessary changes from your arch maintainer's tree.
from what i have heard (from linux-kernel) linus doesn't like to get huge patches. he likes to get small patches that do one thing, since that's easier to review.
the linppc folks have had a hard time accepting this. they want to send one huge patch to get the ppc architecture up-to-date.
it's not a new problem. see this bit on kernel traffic, which covers some of it. there was another thread, where linus flamed people for sending huge patches, but i can't find it atm.
--
I think we may be missing part of the story here... we did not get an explanation of how linus is justifying rejections and such. Anybody have more info?
The first priority for 2.4.x has to be to get it rock solid for the majority of users (and unfortunately for most definitions that means x86). Linus has also been avoiding making vast numbers of changes in one go while working on the really hard to debug and critical fixes to the core code. In the meantime I've been merging chunks of architecture code into the -ac tree ready to go as I get them.
A good solid well maintained self sufficient ppc tree is one of the reasons we can do that of course
Anyone who's ever read the linux-kernel mailing list knows how vindictive and political Linus is. There's nothing he loves more than excluding platforms from HIS kernel (he's very protective of it, he only let's a couple of people submit changes, and even then only if they pay him a royalty).
Also, this problem just came out of the blue. It certainly was never discussed (and re-discussed and re-discussed ad nauseum) over the ISDN patches.
Get a grip people.
--
Non-meta-modded "Overrated" mods are killing Slashdot
(Hey Ryan! Here's your proof!)