Re: kernel-patch questions
> >> Here's the latest compile errors from my most recent attempt to
> >> compile the 2.2.12 kernel.
> > Sing after me: there is no 2.2.12 kernel source for m68k
> > look at sunsite.dk or a mirror:
> > ftp.uni-erlangen.de:/pub/Linux/680x0/v2.2
> > -r--r--r-- 1 ftplinux ftpfau 14037509 Jul 19 1999 linux-2.2.10.tar.gz
> >
> >
>
> Fair enough. My question, then, is to the one who compiled the 2.2.14 kernel
> for the macs: how did you do it? That's the one I'm running on right now,
> and it works, I just want to build firewall stuff into a kernel after 2.2.10
> (because the net-masq HOWTO says there is a bug in the 2.2.10 code dealing
> with IP-chains IIRC)
andrew@macduff.dhs.org is the one to ask. And the linux-mac68k list is the
more appropriate place to ask. Don't get me started on how useful I find
the linux-mac68k vs. linux-m68k list split, just subscribe there or simply
read that lists's archives (see the www.mac.linux-m68k.org web site for
instructions).
> Does this mean that we are forking the code for the linux kernel?
No it doesn't. Each of the several architectures have a group of
developers that work on that specific port, keep their own development
source on CVS or bitkeeper archives or just on the developers' home
machine with occasional FTP releases. It's been going on for ages
(vger.rutgers.edu had a lot of ports, linuxcare.au or formerly ANU had the
PPC port, ftp.uni-erlangen.de and sunsite.auc.dk the m68k port). We're no
different than the others - other than that we were first, worked entirely
independent from Linus as there were no other ports or precedents and
Linus doesn't like some design decisions the m68k port had to make based
on its rather unique situation (combining a number of vendor platforms
that share little beyond the CPU, and the odd SCSI or serial controller
chips). The one thing he didn't like was the way we abstracted the serial
layer, the other was the framebuffer video concept. We won on the latter.
Changes from the mainstream kernel are propagated to the m68k kernel when
the m68k maintainer bothers to release a new version, and m68k changes are
propagated back either via the same way, or someone else needs to send
patches to the big guys (Alan was doing that for some time with Mac
related changes). This is no fork, just the consequence of ongoing work on
the kernel by all ports. In a similar way, Mac as the m68k subarch
currently requiring most effort runs a separate development kernel series
and happened to pass mainstream m68k mainly because 2.3 is too unstable on
Mac whereas others focus on 2.3 and don't invest much work on 2.2. That's
not a fork either, people actually talk to each other and exchange patches
on occasion to get things back in line.
Michael
Reply to: