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
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
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
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
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
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
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 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
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/
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/
