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/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:10 EST