Slashdot Log In
The Silent Kernel Platform War?
Posted by
Cliff
on Tue Feb 13, 2001 12:57 PM
from the quietly-taking-the-other-road dept.
from the quietly-taking-the-other-road dept.
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?"
This discussion has been archived.
No new comments can be posted.
The Silent Kernel Platform War?
|
Log In/Create an Account
| Top
| 242 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Re:Maybe the submitted code is plainly poor? (Score:3)
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.
CVS Repo? (Score:3)
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. [bitmover.com]
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. [bartleby.com] 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...
Re:I agree (Score:3)
The Kernel Forked Long Ago (Score:3)
Re:one sided? (Score:3)
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.
--
There's been a separate PPC tree for a long time (Score:3)
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
Re:This wouldn't surprise me (Score:3)
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
Re:This wouldn't surprise me (Score:3)
So where is Windows for PPC?
Re:one sided? (Score:3)
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.
Nothing new here (Score:3)
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.
Re:Here's how! (Score:3)
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
Look at the history... (Score:3)
http://kt.linuxcare.com/kernel-traffic/kt20010108_ 101.epl#7 [linuxcare.com], http://kt.linuxcare.com/kernel-traffic/kt20001127_ 95.epl#6 [linuxcare.com]
and especially: http://kt.linuxcare.com/kernel-traffic/kt20001002_ 87.epl#3 [linuxcare.com], http://kt.linuxcare.com/kernel-traffic/kt20001010_ 88.epl#7 [linuxcare.com].
Have a good read. KernelTraffic Rocks.
-Chris
http://www.nondot.org/~sabre/os/ [nondot.org]
Re:one sided? (Score:3)
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?
It has been this way for some time... (Score:3)
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.
Older PPC Macs incompatible with Ones, Zeros (Score:3)
Zeros, Ones, and sometimes Twos.
I could kick my own ass for thinking different [ridiculopathy.com].
Re:Kiss my furry ass! (Score:4)
You must be new...
--
It may be nothing insideous (Score:4)
I'd hope that architecture politics stay away from the linux kernel.
Re:one sided? (Score:5)
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 [linuxcare.com] 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.
Indeed. (Score:5)
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...Word from a PPC kernel hacker (Facts) (Score:5)
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.
No big deal (Score:5)
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.
calm down... (Score:5)
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 [linuxcare.com] 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.
--
one sided? (Score:5)
Architecture Merges (Score:5)
A good solid well maintained self sufficient ppc tree is one of the reasons we can do that of course
Re:The Kernel Forked Long Ago (Score:5)
Incorrect. Debian ships with the original Linus kernel tarball. There are some kernels that you can install with various patches applied, but everything is available as a *.deb or a *.[dsc,diff,orig.tar.gz].
In addition, Debian does not commit a Red Hat-ism and package such awful software renames like kgcc. Why not call it what it is, gcc-2.7.2. I mean, come on. Pull the wool over the lusers eyes, don't ya. "Yeah. Red Hat has a special compiler for the Kernel..." Whatever.
Another nice thing about Debian's kernel packaging is that the very tools the developers use are available to the average user.
--
Yes, that's right (Score:5)
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.
--