2.6.0-test1 devfs question

Quoted 4 lines

Is the problem simply that the device has moved from /dev/md1 to /dev/md/1? If so, is this change sufficient?

drivers/md/md.c 2003-07-26 11:25:15.000000000 -0700 int __init md_init(void) · line 3509

Quoted 10 lines

diff -puN drivers/md/md.c~a drivers/md/md.c

drivers/md/md.c 2003-07-26 11:25:15.000000000 -0700 renamed from drivers/md/md.c~a 2003-07-26 11:24:58.000000000 -0700 +1 -1

@@ -3505,7 +3505,7 @@ int __init md_init(void)
        for (minor=0; minor < MAX_MD_DEVS; ++minor) {
                devfs_mk_bdev(MKDEV(MAJOR_NR, minor),
                                S_IFBLK|S_IRUSR|S_IWUSR,
-                               "md/%d", minor);
+                               "md%d", minor);
        }

should not such things be done by devfsd in user space?

This patch makes it even more incompatible with 2.4 ...

Quoted 15 lines · Andrey Borzenkov

drivers/md/md.c 2003-07-26 11:25:15.000000000 -0700 int __init md_init(void) · line 3509

Quoted 13 lines

Is the problem simply that the device has moved from /dev/md1 to /dev/md/1? If so, is this change sufficient?

diff -puN drivers/md/md.c~a drivers/md/md.c

drivers/md/md.c 2003-07-26 11:25:15.000000000 -0700 renamed from drivers/md/md.c~a 2003-07-26 11:24:58.000000000 -0700 +1 -1

@@ -3505,7 +3505,7 @@ int __init md_init(void)
        for (minor=0; minor < MAX_MD_DEVS; ++minor) {
                devfs_mk_bdev(MKDEV(MAJOR_NR, minor),
                                S_IFBLK|S_IRUSR|S_IWUSR,
-                               "md/%d", minor);
+                               "md%d", minor);
        }

should not such things be done by devfsd in user space?

Darned if I know - I do not have operational experience with devfs.

Quoted 1 line

This patch makes it even more incompatible with 2.4 ...

The patch is broken - 2.4 does /dev/md/2 as well.

So what is the bug? Why are people suddenly having problems with this?

it is hard to tell with the amount of information provided in bug report (even error message is not given). We have three cases here:

root=123456 (real major/minor number) or root=/dev/md2 (literal string). In both cases init/do_mount_devfs.c:create_dev() should notice that neither /dev/123456 nor /dev/md2 exist, search /dev for ROOT_DEV and create link from /dev/root to real device. If it does not work somethig is broken here, people who can reproduce it should add printk's to create_dev and find_in_devfs to see what happens. It may fail for /dev/md2 if block device name in sysfs differs from "md2" because then it won't find correct ROOT_DEV

root=/dev/md/2 (literal string) should work simply because /dev/root is linked directly to /dev/md/2

I do not have any raid devices nor possibility to create them so I cannot test.