Am Montag, 21. Mai 2007 22:48 schrieben Sie:
> On 5/21/07, Ken Chen <[EMAIL PROTECTED]> wrote:
> > The easiest way is to reinstate max_loop and create "max_loop" device
> > up front at module load time. However, that will lose all the "fancy
> > on-demand device instantiation feature".
> >
> > So I propose we do the following:
> >
> > 1. have the module honor "max_loop" parameter and create that many
> > device upfront on module load (max_loop will also be a hard max) iff
> > user specify the parameter.
> > 2. if max_loop is not specified, default create 8 loop device. User
> > can extent more loop device by create device node themselves and have
> > kernel automatically instantiate loop device on-demand.
> >
> > Is this acceptable? Patch in a bit.
>
> Could people who has problem with loop device please test this? I
> tested it on my Ubuntu feisty distribution and it works fine. Though I
> typically don't use loop device at all.
>
> ---
>
> The kernel on-demand loop device instantiation breaks several user
> space tools as the tools are not ready to cope with the "on-demand
> feature". Fix it by instantiate default 8 loop devices and also
> reinstate max_loop module parameter.
>
> Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
>
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index 5526ead..0aae8d8 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -1354,7 +1354,7 @@ #endif
> */
> static int max_loop;
> module_param(max_loop, int, 0);
> -MODULE_PARM_DESC(max_loop, "obsolete, loop device is created on-demand");
> +MODULE_PARM_DESC(max_loop, "Maximum number of loop devices");
> MODULE_LICENSE("GPL");
> MODULE_ALIAS_BLOCKDEV_MAJOR(LOOP_MAJOR);
>
> @@ -1462,34 +1462,66 @@ static struct kobject *loop_probe(dev_t
> return kobj;
> }
>
> -static int __init loop_init(void)
> -{
> - if (register_blkdev(LOOP_MAJOR, "loop"))
> - return -EIO;
> - blk_register_region(MKDEV(LOOP_MAJOR, 0), 1UL << MINORBITS,
> - THIS_MODULE, loop_probe, NULL, NULL);
> -
> - if (max_loop) {
> - printk(KERN_INFO "loop: the max_loop option is obsolete "
> - "and will be removed in March 2008\n");
> -
> - }
> - printk(KERN_INFO "loop: module loaded\n");
> - return 0;
> -}
> -
> static void __exit loop_exit(void)
> {
> + unsigned long range;
> struct loop_device *lo, *next;
>
> + range = max_loop ? max_loop : 1UL << MINORBITS;
> +
> list_for_each_entry_safe(lo, next, &loop_devices, lo_list)
> loop_del_one(lo);
>
> - blk_unregister_region(MKDEV(LOOP_MAJOR, 0), 1UL << MINORBITS);
> + blk_unregister_region(MKDEV(LOOP_MAJOR, 0), range);
> if (unregister_blkdev(LOOP_MAJOR, "loop"))
> printk(KERN_WARNING "loop: cannot unregister blkdev\n");
> }
>
> +static int __init loop_init(void)
> +{
> + int i, nr;
> + unsigned long range;
> +
> + /*
> + * loop module now has a feature to instantiate underlying device
> + * structure on-demand, provided that there is an access dev node.
> + * However, this will not work well with user space tool that doesn't
> + * know about such "feature". In order to not break any existing
> + * tool, we do the following:
> + *
> + * (1) if max_loop is specified, create that many upfront, and this
> + * also becomes a hard limit.
> + * (2) if max_loop is not specified, create 8 loop device on module
> + * load, user can further extend loop device by create dev node
> + * themselves and have kernel automatically instantiate actual
> + * device on-demand.
> + */
> + if (max_loop) {
> + nr = max_loop;
> + range = max_loop;
> + } else {
> + nr = 8;
> + range = 1UL << MINORBITS;
> + }
> +
> + if (register_blkdev(LOOP_MAJOR, "loop"))
> + return -EIO;
> + blk_register_region(MKDEV(LOOP_MAJOR, 0), range,
> + THIS_MODULE, loop_probe, NULL, NULL);
> +
> + for (i = 0; i < nr; i++) {
> + if (!loop_init_one(i))
> + goto err;
> + }
> +
> + printk(KERN_INFO "loop: module loaded\n");
> + return 0;
> +err:
> + loop_exit();
> + printk(KERN_INFO "loop: out of memory\n");
> + return -ENOMEM;
> +}
> +
> module_init(loop_init);
> module_exit(loop_exit);
Thank you, Ken :)
Excellent work, everything runs as expected.
Starting compilation of 2.6.22-rc2 I get the following nasty messages:
scripts/kconfig/conf -s arch/i386/Kconfig
drivers/macintosh/Kconfig:116:warning: 'select' used by config
symbol 'PMAC_APM_EMU' refers to undefined symbol 'SYS_SUPPORTS_APM_EMULATION'
drivers/net/Kconfig:2283:warning: 'select' used by config symbol 'UCC_GETH'
refers to undefined symbol 'UCC_FAST'
drivers/input/keyboard/Kconfig:170:warning: 'select' used by config
symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
drivers/input/mouse/Kconfig:182:warning: 'select' used by config
symbol 'MOUSE_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
But, please note, that has nothing to do with the loop issue, which is solved
with this patch.
Other sidenote:
I meanwhile tried to find out why my AMD K7 machine oopses with 2.6.21.1.
I first suspected sis5513 ide module, reverted all its dependencies, even
changed a Makefile, but the Oops is still there after 10 modules reverted. I
am standing in the dark, although I really would like to help to close down
2.6.21.x "cleanly".
On Intel P 4 machines this Oops does not happen at all, only on the AMD K7
machine.
Already planned to start a new thread but instead of wild guessing around I do
not have any idea wht the reason for the kernel Oops could be.
Best Regards and Thanks
Uwe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
