Re: SCSI scanning changes break RAID autorun
[Matthew Kirkwood] > +ifeq ($(CONFIG_BLK_DEV_MD),y) > +SUB_DIRS += md > +MOD_SUB_DIRS += md > +else > + ifeq ($(CONFIG_BLK_DEV_MD),m) > + MOD_SUB_DIRS += md >endif > endif > Drop the 'else' bit; CONFIG_BLK_DEV_MD cannot be 'm'. > +obj-n:= > +obj- := These two variables are unused, don't bother initializing them. We only care about obj-y and obj-m. Rest looks OK (eyeballed, not tested). Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI scanning changes break RAID autorun
In article <[EMAIL PROTECTED]>, Linus Torvalds <[EMAIL PROTECTED]> wrote: > [ Btw, has autorun ever worked with non-scsi devices? Yes, with IDE disks at least. -- Shields. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI scanning changes break RAID autorun
Linus Torvalds writes: > [ Btw, has autorun ever worked with non-scsi devices? They've mostly had > the new initialization order for a long time.. ] Hmm, I hope it will do, since a 2.2.17 kernel with Ingos RAID patches works, and it'd be a shame to break all those RAID root filesystems out there for 2.4. (says me who only got Ingo raid running on 2.2.17 a couple of days ago on ARM). ;) _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI scanning changes break RAID autorun
On Tue, 19 Sep 2000, Linus Torvalds wrote:
> > moving the software RAID drivers into drivers/md/,
> Make it so.
OK. Apply the attached diff and then:
$ mv drivers/block/{md,raid{0,1,5},xor}.c drivers/md/
and all might be well.
The Config.in should probably move at some stage too.
I'm not very au-fait with the kernel build system (nor
makefiles in general) so I'm not sure it's 100% correct,
but it build and linked with my .config, so it can't be
all bad.
Matthew.
diff -ruN linux-2.4.0-test8/Makefile linux/Makefile
--- linux-2.4.0-test8/Makefile Sun Sep 10 12:36:04 2000
+++ linux/Makefile Tue Sep 19 17:40:20 2000
@@ -176,6 +176,7 @@
DRIVERS-$(CONFIG_I2C) += drivers/i2c/i2c.o
DRIVERS-$(CONFIG_PHONE) += drivers/telephony/telephony.a
DRIVERS-$(CONFIG_ACPI_INTERPRETER) += drivers/acpi/acpi.o
+DRIVERS-$(CONFIG_BLK_DEV_MD) += drivers/md/mddev.o
DRIVERS += $(DRIVERS-y)
diff -ruN linux-2.4.0-test8/drivers/Makefile linux/drivers/Makefile
--- linux-2.4.0-test8/drivers/Makefile Sun Sep 3 19:35:31 2000
+++ linux/drivers/Makefile Tue Sep 19 17:16:40 2000
@@ -12,7 +12,7 @@
ALL_SUB_DIRS := $(SUB_DIRS) pci sgi ide scsi sbus cdrom isdn pnp i2o \
ieee1394 macintosh video dio zorro fc4 \
usb nubus tc atm pcmcia i2c telephony \
- acpi mtd input
+ acpi mtd input md
ifdef CONFIG_DIO
SUB_DIRS += dio
@@ -128,6 +128,15 @@
else
ifeq ($(CONFIG_SCSI),m)
MOD_SUB_DIRS += scsi
+ endif
+endif
+
+ifeq ($(CONFIG_BLK_DEV_MD),y)
+SUB_DIRS += md
+MOD_SUB_DIRS += md
+else
+ ifeq ($(CONFIG_BLK_DEV_MD),m)
+ MOD_SUB_DIRS += md
endif
endif
diff -ruN linux-2.4.0-test8/drivers/block/Makefile linux/drivers/block/Makefile
--- linux-2.4.0-test8/drivers/block/MakefileSun Sep 3 19:35:02 2000
+++ linux/drivers/block/MakefileTue Sep 19 17:45:30 2000
@@ -14,7 +14,7 @@
O_TARGET := block.o
-export-objs:= ll_rw_blk.o blkpg.o loop.o DAC960.o md.o xor.o
+export-objs:= ll_rw_blk.o blkpg.o loop.o DAC960.o
list-multi := lvm-mod.o
lvm-mod-objs := lvm.o lvm-snap.o
@@ -35,12 +35,6 @@
obj-$(CONFIG_BLK_CPQ_DA) += cpqarray.o
obj-$(CONFIG_BLK_DEV_DAC960) += DAC960.o
obj-$(CONFIG_BLK_DEV_LVM) += lvm-mod.o
-
-obj-$(CONFIG_BLK_DEV_MD) += md.o
-obj-$(CONFIG_MD_LINEAR)+= linear.o
-obj-$(CONFIG_MD_RAID0) += raid0.o
-obj-$(CONFIG_MD_RAID1) += raid1.o
-obj-$(CONFIG_MD_RAID5) += raid5.o xor.o
obj-$(CONFIG_BLK_DEV_NBD) += nbd.o
diff -ruN linux-2.4.0-test8/drivers/md/Makefile linux/drivers/md/Makefile
--- linux-2.4.0-test8/drivers/md/Makefile Thu Jan 1 01:00:00 1970
+++ linux/drivers/md/Makefile Tue Sep 19 17:45:22 2000
@@ -0,0 +1,29 @@
+#
+# Makefile for the kernel software RAID drivers.
+#
+
+O_TARGET := mddev.o
+SUB_DIRS :=
+ALL_SUB_DIRS :=
+MOD_SUB_DIRS :=
+
+export-objs:= md.o xor.o
+
+obj-y :=
+obj-m :=
+obj-n :=
+obj- :=
+
+obj-$(CONFIG_BLK_DEV_MD) += md.o
+obj-$(CONFIG_MD_LINEAR)+= linear.o
+obj-$(CONFIG_MD_RAID0) += raid0.o
+obj-$(CONFIG_MD_RAID1) += raid1.o
+obj-$(CONFIG_MD_RAID5) += raid5.o xor.o
+
+# Translate to Rules.make lists.
+O_OBJS := $(filter-out $(export-objs), $(obj-y))
+OX_OBJS:= $(filter $(export-objs), $(obj-y))
+M_OBJS := $(sort $(filter-out $(export-objs), $(obj-m)))
+MX_OBJS:= $(sort $(filter $(export-objs), $(obj-m)))
+
+include $(TOPDIR)/Rules.make
Re: SCSI scanning changes break RAID autorun
On Tue, 19 Sep 2000, Matthew Kirkwood wrote: > > It's probably solely an init-order thing but, short of > moving the software RAID drivers into drivers/md/, I > can't see an easy way to fix it. That would probably not be a bad fix - especially as some people want to split up xor.c into multiple files and I'd hate to clutter up drivers/block any more than necessary anyway. Make it so. [ Btw, has autorun ever worked with non-scsi devices? They've mostly had the new initialization order for a long time.. ] Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
SCSI scanning changes break RAID autorun
Hi, It would appear that the changes in pre3 and pre4 break RAID autorun. This is rather bothersome for those who have RAIDed root filesystems. It's probably solely an init-order thing but, short of moving the software RAID drivers into drivers/md/, I can't see an easy way to fix it. cheers, Matthew. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
