I'm sorry about the tone of this e-mail, but it is somewhat painful when,
after downloading a new kernel to play with, it doesn't compile on the
ppc. It isn't even big problems either. A single line (#include
<linux/pm.h>) is missing from pc_keyb.c and has been for at least three
-ac releases. Now, process.c in arch/ppc/kernel/ dies from an undeclared
identifier (init_mmap).
I'm sure the appropriate response would be to fix them myself, but I don't
know enough about the kernel or the ppc arhitecture. I'm also sure that
if Theo (or anyone like him) was to read this s/he would tell me to stop
whining.
Anyway, the real question is, why does the ppc arhitecture /always/ break
between versions?
I'll stop complaining now.
Regards,
-Mike
Try the BK PPC trees at
http://ppc.bkbits.net
you can clone any one of those with a
bk clone http://ppc.bkbits.net/<TREE_NAME>
you can get BK at http://www.bitmover.com/download
On Fri, Oct 12, 2001 at 10:08:39AM -0700, Mike Borrelli wrote:
> I'm sorry about the tone of this e-mail, but it is somewhat painful when,
> after downloading a new kernel to play with, it doesn't compile on the
> ppc. It isn't even big problems either. A single line (#include
> <linux/pm.h>) is missing from pc_keyb.c and has been for at least three
> -ac releases. Now, process.c in arch/ppc/kernel/ dies from an undeclared
> identifier (init_mmap).
>
> I'm sure the appropriate response would be to fix them myself, but I don't
> know enough about the kernel or the ppc arhitecture. I'm also sure that
> if Theo (or anyone like him) was to read this s/he would tell me to stop
> whining.
>
> Anyway, the real question is, why does the ppc arhitecture /always/ break
> between versions?
>
> I'll stop complaining now.
>
> Regards,
> -Mike
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Fri, Oct 12, 2001 at 10:08:39AM -0700, Mike Borrelli wrote:
> It isn't even big problems either. A single line (#include
> <linux/pm.h>) is missing from pc_keyb.c and has been for at least three
> -ac releases. Now, process.c in arch/ppc/kernel/ dies from an undeclared
> identifier (init_mmap).
>
> Anyway, the real question is, why does the ppc arhitecture /always/ break
> between versions?
An -ac kernel is SUPPOSED to break. It's not a release kernel. WHEN it
breaks, it gets fixed, and then it becomes a release kernel.
Seems simple enough.
If you want intermediate kernel revisions that don't break, head over to
http://penguinppc.org and look at how to rsync yourself a benh or bk
kernel tree.
--
Marc Wilson
[email protected]
[email protected]
On Fri, 12 Oct 2001 10:56:43 -0700, Marc Wilson
<[email protected]> wrote:
>On Fri, Oct 12, 2001 at 10:08:39AM -0700, Mike Borrelli wrote:
>> It isn't even big problems either. A single line (#include
>> <linux/pm.h>) is missing from pc_keyb.c and has been for at least three
>> -ac releases. Now, process.c in arch/ppc/kernel/ dies from an undeclared
>> identifier (init_mmap).
>>
>> Anyway, the real question is, why does the ppc arhitecture /always/ break
>> between versions?
>
>An -ac kernel is SUPPOSED to break. It's not a release kernel. WHEN it
>breaks, it gets fixed, and then it becomes a release kernel.
>
>Seems simple enough.
When you use a development kernel (kernel created by developers) you
have joined the test team. Breakages and bugs and failures are GOOD
things that help perfect and stabilize the products. Success reports
are interesting but usually worthless.
john alvord
On Fri, Oct 12, 2001 at 10:30:19AM -0700, Larry McVoy wrote:
> you can get BK at http://www.bitmover.com/download
Beware. BK is not free software.
On Fri, Oct 12, 2001 at 10:30:19AM -0700, Larry McVoy wrote:
> Try the BK PPC trees at
>
> http://ppc.bkbits.net
>
> you can clone any one of those with a
>
> bk clone http://ppc.bkbits.net/<TREE_NAME>
>
> you can get BK at http://www.bitmover.com/download
>
You can also get the same trees with rsync. Check out penguinppc.org.
Mike Borrelli writes:
> I'm sorry about the tone of this e-mail, but it is somewhat painful when,
> after downloading a new kernel to play with, it doesn't compile on the
> ppc. It isn't even big problems either. A single line (#include
> <linux/pm.h>) is missing from pc_keyb.c and has been for at least three
> -ac releases. Now, process.c in arch/ppc/kernel/ dies from an undeclared
> identifier (init_mmap).
...
> Anyway, the real question is, why does the ppc arhitecture /always/ break
> between versions?
At the most recent Ottata Linux Symposium, there was a PowerPC
session with about 20 people. Somebody did a poll, asking what
people used. I was the only person who dared to use a kernel
from Linus. Everone else was using the BenH and BitKeeper ones.
This is a sorry state of affairs. If people are off using kernels
from other places, there isn't a great incentive to keep the
official Linus kernel updated. Nobody uses it anyway.
Elimination of these non-Linus PowerPC trees would be great.
(at least the "stable" ones should go, as they lure people
away from the one true source tree)
>At the most recent Ottata Linux Symposium, there was a PowerPC
>session with about 20 people. Somebody did a poll, asking what
>people used. I was the only person who dared to use a kernel
>from Linus. Everone else was using the BenH and BitKeeper ones.
>
>This is a sorry state of affairs. If people are off using kernels
>from other places, there isn't a great incentive to keep the
>official Linus kernel updated. Nobody uses it anyway.
>
>Elimination of these non-Linus PowerPC trees would be great.
>(at least the "stable" ones should go, as they lure people
>away from the one true source tree)
That's not exactly how things happen.
Most users use the kernel that comes with their distro, which,
as usual in the linux world, is made of bits from here and there.
Some mac users use my kernels because they contain some bleeding
edge stuff that is not ready to be in a stable tree. It's an
experimental kernel and doesn't claim to be stable.
Now, PPC is a lot of very different machines, coordinating them
all is a complicated task, and having our own tree to handle the
merge work is pretty useful. This is the bk _2_4 "stable" tree, any
thing in there is supposed to be "pending" for Linus.
We would probably be happy to submit all what we have in _2_4_devel
once 2.5 is opened. It's our developemental tree. Occasionally,
parts of it are considered stable enough to get to _2_4, and
at that point, it might happen to take some time before beeing
fully merged in Linus tree, but we are doing our best.
Ben.
Mike Borrelli writes:
> I'm sorry about the tone of this e-mail, but it is somewhat painful when,
> after downloading a new kernel to play with, it doesn't compile on the
> ppc. It isn't even big problems either. A single line (#include
> <linux/pm.h>) is missing from pc_keyb.c and has been for at least three
> -ac releases. Now, process.c in arch/ppc/kernel/ dies from an undeclared
> identifier (init_mmap).
I'm afraid I am to blame for this one. It looks like we sent Alan a
patch which isn't appropriate for Alan's tree (because Alan's and
Linus' trees VM system is different). Here is a patch to reverse the
breakage.
> Anyway, the real question is, why does the ppc arhitecture /always/ break
> between versions?
Well, the port maintainers don't get any earlier access to the
releases than everyone else. So if some change breaks the compile for
PPC (or any other architecture), we just have to send a patch to Linus
or Alan and hope that it gets accepted for the next release (when
there could easily be another change that breaks things in some other
way, of course). That said, Alan is usually very good about accepting
our patches in a timely fashion, and as I said, the process.c breakage
is our fault not his.
With Linus' trees, it would be nice if there were some restrictions on
what sort of changes can go in between the last prerelease and the
final release - if it was restricted to changes under arch/ and
include/asm-*, obvious compile fixes, or really critical bug fixes,
then there would be a better chance that the final release would work
for most architectures. But that does not seem to be a priority at
this stage.
Paul.
diff -urN ac2412-1/arch/ppc/kernel/process.c acppc/arch/ppc/kernel/process.c
--- ac2412-1/arch/ppc/kernel/process.c Wed Oct 10 12:38:52 2001
+++ acppc/arch/ppc/kernel/process.c Sat Oct 13 16:50:32 2001
@@ -48,6 +48,7 @@
struct task_struct *last_task_used_math = NULL;
struct task_struct *last_task_used_altivec = NULL;
+static struct vm_area_struct init_mmap = INIT_MMAP;
static struct fs_struct init_fs = INIT_FS;
static struct files_struct init_files = INIT_FILES;
static struct signal_struct init_signals = INIT_SIGNALS;
On Sat, Oct 13, Albert D. Cahalan wrote:
> This is a sorry state of affairs. If people are off using kernels
> from other places, there isn't a great incentive to keep the
> official Linus kernel updated. Nobody uses it anyway.
reality check please, Linus merged a lot from linuxppc_2_4.
Gruss Olaf
--
$ man clone
BUGS
Main feature not yet implemented...
On Sat, Oct 13, 2001 at 12:52:16AM -0400, Albert D. Cahalan wrote:
> Mike Borrelli writes:
> > Anyway, the real question is, why does the ppc arhitecture /always/ break
> > between versions?
>
> At the most recent Ottata Linux Symposium, there was a PowerPC
> session with about 20 people. Somebody did a poll, asking what
> people used. I was the only person who dared to use a kernel
> from Linus. Everone else was using the BenH and BitKeeper ones.
>
> This is a sorry state of affairs.
Actually, this is normal for new ports on Linux. PPC is relatively new,
m68k is developed with their own cvs, as is Intel IA64. I'm sure others
will be able to quote about other arches...
On Sat, Oct 13, 2001 at 11:47:29AM -0700, Mike Fedyk wrote:
> On Sat, Oct 13, 2001 at 12:52:16AM -0400, Albert D. Cahalan wrote:
> > Mike Borrelli writes:
> > > Anyway, the real question is, why does the ppc arhitecture /always/ break
> > > between versions?
> >
> > At the most recent Ottata Linux Symposium, there was a PowerPC
> > session with about 20 people. Somebody did a poll, asking what
> > people used. I was the only person who dared to use a kernel
> > from Linus. Everone else was using the BenH and BitKeeper ones.
> >
> > This is a sorry state of affairs.
>
> Actually, this is normal for new ports on Linux. PPC is relatively new,
> m68k is developed with their own cvs, as is Intel IA64. I'm sure others
> will be able to quote about other arches...
Actually, this is a normal state of affairs for !i386. PPC has actually
been around in some form or another for 5 years almost... (at least?).
m68k is older than that. It's sort of a given that the Linus tree will
be a bit behind. But as far as PPC goes, we were actually pretty close
in 2.4.10 and 2.4.12 and the stable PPC tree had very few (and for the
most part unimportant) differences.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Sat, 13 Oct 2001, Mike Fedyk wrote:
> On Sat, Oct 13, 2001 at 12:52:16AM -0400, Albert D. Cahalan wrote:
> > Mike Borrelli writes:
> > > Anyway, the real question is, why does the ppc arhitecture /always/ break
> > > between versions?
> >
> > At the most recent Ottata Linux Symposium, there was a PowerPC
> > session with about 20 people. Somebody did a poll, asking what
> > people used. I was the only person who dared to use a kernel
> > from Linus. Everone else was using the BenH and BitKeeper ones.
> >
> > This is a sorry state of affairs.
>
> Actually, this is normal for new ports on Linux. PPC is relatively new,
> m68k is developed with their own cvs, as is Intel IA64. I'm sure others
> will be able to quote about other arches...
Nah, m68k still doesn't have its own CVS, due to `political' issues :-(
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds