Andrew Morton wrote:
On Fri, 30 Mar 2007 02:25:37 -0700
"Ken Chen" <[EMAIL PROTECTED]> wrote:
-module_param(max_loop, int, 0);
-MODULE_PARM_DESC(max_loop, "Maximum number of loop devices (1-256)");
So.. this change will cause a fatal error for anyone who is presently
using max_loop, won't it? If they're doing that within their
initramfs/initrd/etc then things could get rather ugly for them.
I consider myself the most precious user of max_loop.
The max_loop parameter would cause a fatal error only in the case if you
modprobe loop manually, for example:
$ modprobe loop max_loop=200
But people don't usually use this, read below.
I don't know how much of a problem this will be in practice - do
people use max_loop much?
yes, but no as a module parameter.
People usually use max_loop as a 'kernel boot parameter' passed in
APPEND section in a boot loader (such as LILO for example), not as a
parameter for module in initrd. Why? Because it's easier; people are
lazy, people compile loop.c into kernel so they don't need to update the
loop.ko module in initrd every time a new Kernel is released.
I believe that IF you _really_ need to preserve the boot parameter, then
the parameter should _not_ be ignored, rather it should have the same
function like before - to limit the loop driver so if you use
max_loop=10 for example, it should not allow loop.c to create more than
10 loops.
And if no parameter is used at all, there will be unlimited amount of
loops. Simply clever :)
This will make it _completely_ backward-compatible, with very small code
change I guess.
Just my two cents.
Thank you for reading so far.
Tomas M
slax.org
-
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/