Re: PATCH: "Pass module parameters" to built-in drivers
On Wed, 24 Jan 2001 08:32:35 -0500, Paul Gortmaker <[EMAIL PROTECTED]> wrote: >I'm curious as to what boot argument equivalent you envision for e.g. > >options ne io=0x280,0x300 irq=10,12 bad=0,1 ne.io=0x280,0x300 ne.irq=10,12 ne.bad=0,1. I might even be generous and handle ne{io=0x280,0x300 irq=10,12 bad=0,1} If a parameter name is unique amongst all compiled in objects then it does not need the object/module name, although it is recommended. - 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: PATCH: "Pass module parameters" to built-in drivers
Keith Owens wrote: > Inconsistent methods for setting the same parameter are bad. I can and > will do this cleanly in 2.5. Parameters will be always be keyed by the > module name, even if they are compiled in. Adding an inconsistent I'm curious as to what boot argument equivalent you envision for e.g. options ne io=0x280,0x300 irq=10,12 bad=0,1 > method to 2.4 then changing to a correct method in 2.5 is a bad idea, > wait until we can do it right. As a related issue, this will allow me (or whoever) to kill off the ether=x,y,z,ethN boot argument for compiled in ethernet drivers at the same time. It made sense back in 1.0/1.2 days when distro kernels were shipped with everything compiled in and ISA cards were the norm. Now it is hardly used and generally a PITA to support. Paul. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com - 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: PATCH: "Pass module parameters" to built-in drivers
Hi! Well, I did a very similar patch about 2.3.3x and it got even included in -acXX during a Linus vacation - but it got dropped for some reason (f.i. such an approach does not work well for multi-file modules, I was told). I re-sent it during the 2.4.0-test phase and got no reply, so I think just adding __setup() stuff manually to every module seems the way to go... :( Richard. On Mon, 22 Jan 2001, Werner Almesberger wrote: > Keith Owens wrote: > > Inconsistent methods for setting the same parameter are bad. I can and > > will do this cleanly in 2.5. > > If your approach isn't overly intrusive (i.e. doesn't require changes > to all files containing module parameters, or such), maybe you could > make a patch for 2.4.x and wave it a little under Linus' nose. Maybe > he likes the scent ;-) > > In any case, once it's in 2.5.x, and if it is as useful as I suspect > it to be, it would probably be back-ported to 2.4 sooner or later. > > - Werner > > -- > _ > / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / > /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ > - > 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/ > -- Richard Guenther <[EMAIL PROTECTED]> WWW: http://www.anatom.uni-tuebingen.de/~richi/ The GLAME Project: http://www.glame.de/ - 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: PATCH: "Pass module parameters" to built-in drivers
On Mon, 22 Jan 2001 21:55:23 + (GMT), Russell King <[EMAIL PROTECTED]> wrote: >Hmm, don't we already have all that __setup() stuff laying around? Ok, >it might not be built into the .o for modules, but it could be. Could >we not do something along the lines of: > >1. User passes parameters on the kernel command line. >2. modprobe reads the kernel command line and sorts out those that > correspond to the __setup() stuff in the module being loaded. >3. modprobe combines in any extra settings from /etc/modules.conf > >IIRC, this would satisfy the original posters intentions, presumably >without too much hastle? Apart from the fact that it is completely backwards from the original intent. The problem is objects that have MODULE_PARM but no __setup. - 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: PATCH: "Pass module parameters" to built-in drivers
Keith Owens writes: > It is part of my total Makefile rewrite for 2.5. A clean > implementation of module parameters mapping to setup code requires the > mapping of a source file to the module it is linked into. That > information is difficult to extract with the current Makefile system, > my rewrite makes it easy. Hmm, don't we already have all that __setup() stuff laying around? Ok, it might not be built into the .o for modules, but it could be. Could we not do something along the lines of: 1. User passes parameters on the kernel command line. 2. modprobe reads the kernel command line and sorts out those that correspond to the __setup() stuff in the module being loaded. 3. modprobe combines in any extra settings from /etc/modules.conf IIRC, this would satisfy the original posters intentions, presumably without too much hastle? -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - 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: PATCH: "Pass module parameters" to built-in drivers
On Mon, 22 Jan 2001 16:56:38 +0100, Werner Almesberger <[EMAIL PROTECTED]> wrote: >Keith Owens wrote: >> Inconsistent methods for setting the same parameter are bad. I can and >> will do this cleanly in 2.5. > >If your approach isn't overly intrusive (i.e. doesn't require changes >to all files containing module parameters, or such), maybe you could >make a patch for 2.4.x and wave it a little under Linus' nose. Maybe >he likes the scent ;-) It is part of my total Makefile rewrite for 2.5. A clean implementation of module parameters mapping to setup code requires the mapping of a source file to the module it is linked into. That information is difficult to extract with the current Makefile system, my rewrite makes it easy. - 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: PATCH: "Pass module parameters" to built-in drivers
Keith Owens wrote: > Inconsistent methods for setting the same parameter are bad. I can and > will do this cleanly in 2.5. If your approach isn't overly intrusive (i.e. doesn't require changes to all files containing module parameters, or such), maybe you could make a patch for 2.4.x and wave it a little under Linus' nose. Maybe he likes the scent ;-) In any case, once it's in 2.5.x, and if it is as useful as I suspect it to be, it would probably be back-ported to 2.4 sooner or later. - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - 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: PATCH: "Pass module parameters" to built-in drivers
On Sun, 21 Jan 2001 15:54:56 +1100, David Luyer <[EMAIL PROTECTED]> wrote: >Here's a proposed v2.4 "quick fix" to allow specifying "module parameters" to >any of the many drivers without option parsers when built in to the kernel. Fundamental problem: you assume that each module is built from a source of the same name, this is not true. For example, scsi_mod is built from several objects, including scsi.c and scsi_scan.c which contain MODULE_PARM. With your patch the user has to do scsi.c:scsihosts="..." scsi_scan.c:max_scsi_luns=n (built in) or options scsi_mod scsihosts="..." max_scsi_luns=n (module) Inconsistent methods for setting the same parameter are bad. I can and will do this cleanly in 2.5. Parameters will be always be keyed by the module name, even if they are compiled in. Adding an inconsistent method to 2.4 then changing to a correct method in 2.5 is a bad idea, wait until we can do it right. - 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/
PATCH: "Pass module parameters" to built-in drivers
Alan, Keith, All, Here's a proposed v2.4 "quick fix" to allow specifying "module parameters" to any of the many drivers without option parsers when built in to the kernel. I understand Keith has intentions to do this differently in v2.5, however I'd be happy if something along these lines could find its way into v2.4, maybe the below, something similar to the below but with the default of "N" instead, or maybe a completely different. I haven't tested it extensively - only so far as that it works just fine with all the modules that I wanted set options for on bootup; none of these are, for example, string or integer list options so those aren't tested. All code is placed in init functions, I'm not sure about where the strings specified as options to generic_parse_function will end up though. Comments/feedback? (and I know without the ".c" would be nicer, but AFAIK that can't be done without either extra run-time code (chop the .c at run-time) or makefile support (-D__FILEBASE__=). diff -urN orig/linux/Documentation/Configure.help linux/Documentation/Configure.help --- orig/linux/Documentation/Configure.help Wed Jan 17 15:30:13 2001 +++ linux/Documentation/Configure.help Sat Jan 20 11:18:41 2001 @@ -3729,6 +3729,14 @@ replacement for kerneld.) Say Y here and read about configuring it in Documentation/kmod.txt. +Module parameter parsing for non-modular drivers +CONFIG_MODPARM_BUILTIN + This allows you to set parameters which are normally passed as + options to modules by specifying the parameter as file.c:var=value + on the kernel command line (eg, xirc2ps_cs.c:lockup_hack=1). + Say Y here if unsure - all additional memory used is freed during + bootup. + ARP daemon support (EXPERIMENTAL) CONFIG_ARPD Normally, the kernel maintains an internal cache which maps IP diff -urN orig/linux/arch/alpha/config.in linux/arch/alpha/config.in --- orig/linux/arch/alpha/config.in Wed Jan 17 15:30:14 2001 +++ linux/arch/alpha/config.in Sat Jan 20 11:21:02 2001 @@ -20,6 +20,7 @@ bool 'Set version information on all symbols for modules' CONFIG_MODVERSIONS bool 'Kernel module loader' CONFIG_KMOD fi +bool 'Module parameter passing for non-modular drivers' CONFIG_MODPARM_BUILTIN endmenu mainmenu_option next_comment diff -urN orig/linux/arch/alpha/defconfig linux/arch/alpha/defconfig --- orig/linux/arch/alpha/defconfig Tue Oct 17 09:38:41 2000 +++ linux/arch/alpha/defconfig Sat Jan 20 11:19:05 2001 @@ -14,6 +14,7 @@ CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y +CONFIG_MODPARM_BUILTIN=y # # General setup diff -urN orig/linux/arch/arm/config.in linux/arch/arm/config.in --- orig/linux/arch/arm/config.in Wed Jan 17 15:30:14 2001 +++ linux/arch/arm/config.inSat Jan 20 11:21:08 2001 @@ -25,6 +25,7 @@ bool ' Set version information on all module symbols' CONFIG_MODVERSIONS bool ' Kernel module loader' CONFIG_KMOD fi +bool 'Module parameter passing for non-modular drivers' CONFIG_MODPARM_BUILTIN endmenu diff -urN orig/linux/arch/arm/defconfig linux/arch/arm/defconfig --- orig/linux/arch/arm/defconfig Tue Jun 20 10:59:33 2000 +++ linux/arch/arm/defconfigSat Jan 20 11:19:11 2001 @@ -42,6 +42,7 @@ CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y +CONFIG_MODPARM_BUILTIN=y # # General setup diff -urN orig/linux/arch/i386/config.in linux/arch/i386/config.in --- orig/linux/arch/i386/config.in Wed Jan 17 15:30:15 2001 +++ linux/arch/i386/config.in Sat Jan 20 11:14:55 2001 @@ -22,6 +22,7 @@ bool ' Set version information on all module symbols' CONFIG_MODVERSIONS bool ' Kernel module loader' CONFIG_KMOD fi +bool 'Module parameter passing for non-modular drivers' CONFIG_MODPARM_BUILTIN endmenu mainmenu_option next_comment diff -urN orig/linux/arch/i386/defconfig linux/arch/i386/defconfig --- orig/linux/arch/i386/defconfig Wed Jan 17 15:30:15 2001 +++ linux/arch/i386/defconfig Sat Jan 20 11:19:14 2001 @@ -17,6 +17,7 @@ CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y +CONFIG_MODPARM_BUILTIN=y # # Processor type and features diff -urN orig/linux/arch/ia64/config.in linux/arch/ia64/config.in --- orig/linux/arch/ia64/config.in Wed Jan 17 15:30:16 2001 +++ linux/arch/ia64/config.in Sat Jan 20 11:21:18 2001 @@ -12,6 +12,7 @@ bool ' Set version information on all module symbols' CONFIG_MODVERSIONS bool ' Kernel module loader' CONFIG_KMOD fi +bool 'Module parameter passing for non-modular drivers' CONFIG_MODPARM_BUILTIN endmenu mainmenu_option next_comment diff -urN orig/linux/arch/ia64/defconfig linux/arch/ia64/defconfig --- orig/linux/arch/ia64/defconfig Fri Jun 23 00:09:44 2000 +++ linux/arch/ia64/defconfig Sat Jan 20 11:19:24 2001 @@ -39,6 +39,7 @@ # Loadable module support # # CONFIG_MODULES is not set +CONFIG_MODPARM_BUILTIN=y # # Parallel port support diff -urN orig/linux/arch/m68k/config.in linux/arch/m68k/config.in --- orig/linux/arch/m68