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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
17 matches
Mail list logo
