lkml.org 
[lkml]   [2000]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [incremental diff] Re: [patch] initrd fix 2.3.48
Date
Ramdisk sans initrd seems to work fine with this patch.  Thank you.

Regards,
Brad

----- Original Message -----
From: "Mike Galbraith" <mikeg@weiden.de>
To: "Bradley D. LaRonde" <brad@ltc.com>
Cc: "linux-kernel" <linux-kernel@vger.rutgers.edu>; "Linus Torvalds"
<torvalds@transmeta.com>
Sent: Wednesday, March 01, 2000 12:51 PM
Subject: [incremental diff] Re: [patch] initrd fix 2.3.48


> On Wed, 1 Mar 2000, Bradley D. LaRonde wrote:
>
> > Test results of latest patch:
> >
> > It seems that it works great for initrd, and for general ramdisk, but
only
> > as long as CONFIG_BLK_DEV_INITRD is defined.
> >
> > However, the file won't even compile if ramdisk is configured without
> > initrd. This is apparently due to initrd_fops being used outside of the
> > #ifdef CONFIG_BLK_DEV_INITRD part.
> >
> > The fact that RD_LOADER and BUILD_CRAMDISK are always defined at the top
of
> > rd.c (except if MODULE is defined) also strikes me as very odd (but that
is
> > not due to this particular fix). Maybe the relationship between
RD_LOADER
> > and CONFIG_BLK_DEV_INITRD is complicating things?
>
> Thanks for testing. The compilation error is because of an erronious
> cleanup change that changed logic. It should be def_blk_fops at that
> point and conditionally set to initrd_fops in rd_open() as in originl.
>
> Someone suggested that I should rediff against 49-2. Attached is the
> logic reinstatment and incremenmtal changes from rd.diff.2.
>
> -Mike
>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.043 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site