xfs
[Top] [All Lists]

Re: Building RH kernel + patches

To: Seth Mos <knuffie@xxxxxxxxx>
Subject: Re: Building RH kernel + patches
From: Steve Lord <lord@xxxxxxx>
Date: Thu, 07 Jun 2001 14:21:21 -0500
Cc: Alan Eldridge <alane@xxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx, cattelan@xxxxxxxxxxx
In-reply-to: Message from Seth Mos <knuffie@xs4all.nl> of "Thu, 07 Jun 2001 21:11:39 +0200." <4.3.2.7.2.20010607210041.033154a0@pop.xs4all.nl>
Sender: owner-linux-xfs@xxxxxxxxxxx
Someone said rawhide now has 2.4.5 based kernel rpms, I have no idea what
is in them. It is probably a lot simpler to do this from an xfs base which
does not have kdb in it. You can get rid of kdb by reverse applying the
latest kdb patch from oss.sgi.com/projects/kdb.

Steve

> At 14:37 7-6-2001 -0400, Alan Eldridge wrote:
> >I'd like to rebuild RH's current rawhide kernel SRPM, but with the 2.4.5 XFS
> >patches applied ... I'm getting sick of __alloc_pages() failed, and "Out of
> >memory: Killing process nnnn".
> >
> >However, it appears that the XFS patch includes *some* of the RH patches.
> >Is there any clear way to determine which RH patches I want to keep, and
> >which are already applied, *and* where in the sequence I want to apply the
> >XFS patch?
> >
> >I'm starting to look through the patches manually, but that's going to
> >really suck. Please tell me there's a better way.
> 
> Good question, I believe Russel Catalan originally did the 2.4.2-XFS kernel 
> that came on the 1.0 installer disk. I think he would be the one to ask.
> There were over 200 patches in the 2.4.2 RH 7.1 kernel so I have no idea 
> were to begin.
> 
> The 2.4.5 is a vanilla tree with xfs and things like kdb added. There might 
> a few things duplicate.
> I can imagine that RH included some of the other SGI patches like High 
> availabilty.
> Just guessing here.
> 
> My best guess would be to start with a 2.4.5 xfs tree and start applying 
> the more harmless patches like added drivers or obvious fixes and see what 
> you end up with.
> 
> Good luck
> 
> --
> Seth
> Every program has two purposes one for which
> it was written and another for which it wasn't
> I use the last kind.



<Prev in Thread] Current Thread [Next in Thread>