Messages in this thread | | | From | "Bradley D. LaRonde" <> | Subject | Re: [incremental diff] Re: [patch] initrd fix 2.3.48 | Date | Wed, 1 Mar 2000 14:23:15 -0500 |
| |
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/
| |