Re: Some 2.6.6 kernel questions
On Tue, Jul 13, 2004 at 09:30:21AM -0400, Albert Cahalan wrote:
> On Tue, 2004-07-13 at 10:18, Sven Luther wrote:
> > On Tue, Jul 13, 2004 at 06:58:21AM -0400, Albert Cahalan wrote:
> > > On Tue, 2004-07-13 at 07:15, Sven Luther wrote:
> > > > On Mon, Jul 12, 2004 at 10:29:25PM -0400, Albert Cahalan wrote:
> > >
> > > > > Just yesterday I grabbed a plain 2.6.8-rc1 kernel
> > > > > from www.kernel.org/pub/linux/ and it works great
> > > > > on my Mac Cube. Perhaps you should try that.
> > > >
> > > > And what about kernel-image-2.6.7-powerpc ? Does it work fine also ? And
> > > > if not did you fill a bug report. If yes, what motivated you to build
> > > > your own kernel over using the debian provided one ?
> > >
> > > I never trust distribution-provided kernels. They are
> > > often full of questionable patches, obsolete, and way
> > > too generic for my taste. They might not even use the
> > > larger 12x22 console font.
> > Bah, whatever. try to stay current, the current trend is to have most
> > debian patches either dropped, or merged upstream. Furthermore, there
> > are some upstream kernel maintainers part of the kernel team since a few
> > weeks, and i believe they probably have a better judgement about patches
> > than even you do.
> If you have anything good, post it to the linux-kernel
Well, christoph has been forwarding most stuff upstream, since he is
also a kernel developer, i tend to let him do that.
> mailing list. Perhaps you could also put the bare patches
> on a web page somewhere. On this list, it would be nice
> to hear when patches are added/removed from the collection
> and why.
Well, the kernel svn is at :
And the patches, both arch-indep ones and powerpc, can be found in :
and in :
As you see, most of the patches are in the generic kernel tree now, and
many of those will go away once 2.6.8 is released.
All subversion commits are logged, at the debian-kernel list, but will
get a separate list later on, i think.
> > As for obsolet, well, that is a bit ridicoulous, as
> > 2.6.7 is the latest release, and it includes some backport of patches
> > that will go in 2.6.8.
> > As for the genericness, since most of the stuff is being modularized,
> > this is no more the case. And if you have some trouble with the config,
> > please fill bug reports.
> I'm not suggesting that the Debian kernel is done poorly.
> It has to work for everybody though, and thus isn't optimized
> for me.
Bah, optimized ? What is the difference between stuff you don't compile
in and stuff that is modular but you don't load ?
> It's nice just copying 3 files to install. It's nice to
> not concern myself with /etc/*mod* and /lib/modules.
Well, you should not, it should just work. This is not yet really the
case, but we are working on it.
> > > The 2.6.7 kernel is certainly obsolete now that
> > > 2.6.8-rc1 is out. :-) I'm only half kidding; the
> > > newer kernel has lots of nice fixes and isn't
> > > generating lots of bug reports.
> > So ? when 2.6.8 will be released, we will package it.
> Sure, but I want the new stuff NOW. :-)
Ok, fine enough.
> > > I know exactly where my kernel is, and exactly where it
> > > came from:
> > >
> > > make menuconfig
> > > make vmlinux
> > > mv System.map-2.6.8-rc1 /boot
> > > mv vmlinux-2.6.8-rc1 /boot
> > > cp config-2.6.8-rc1 /boot
> > > joe /etc/yaboot.conf
> > > ybin
> > Yes, sure, but you also do know the same about the debian kernel. OR at
> > least you could.
> Sometimes I simply must run the latest official kernel.
> I may need to test procps on it or create a patch for Linus+AKPM.
> Thus, I must be familiar with this way of handling kernels.
Ok. Well, i understand, i do kernel development also.
> If I ran Debian kernels, I'd be mixing two systems. I don't
> know what the install scripts might do to /etc/yaboot.conf,
> and it might be unpleasant to find out. Sure, I could rip
Well, since the debian kernels are 2.6.7-powerpc, or something such, you
just use make-kpkg --append-to-version, and you create a kernel which
can pe parallel instaleld. yaboot should be able to cope with that, or
is somewhat buggy and needs to be fixed.
> apart the *.deb with ar and tar, then dig through all the
> packaging control files... but that seems like a lot of work
> and risk for little gain. (eh, what gain?)
Huh ? Whatever for.