Hello!
It would be nice to constrain RCU_TORTURE_TEST to "n" or "m", excluding
"y", since "y" gives anti-social results that I have never seen a use
for. So I tried adding a "range n m" to the Kconfig.debug entry for
RCU_TORTURE_TEST. This gives me the following warning at "make xconfig"
time:
lib/Kconfig.debug:386:warning: range is only allowed for int or hex symbols
and xconfig ignores the restriction.
A few clumsy hacks get rid of the error message, but fail to cause
xconfig to enforce the limit.
Is there some other way to prohibit modules from being compiled into
the main kernel?
Thanx, Paul
On Tue, 15 May 2007 16:30:02 -0700 Paul E. McKenney wrote:
> Hello!
>
> It would be nice to constrain RCU_TORTURE_TEST to "n" or "m", excluding
> "y", since "y" gives anti-social results that I have never seen a use
> for. So I tried adding a "range n m" to the Kconfig.debug entry for
> RCU_TORTURE_TEST. This gives me the following warning at "make xconfig"
> time:
>
> lib/Kconfig.debug:386:warning: range is only allowed for int or hex symbols
>
> and xconfig ignores the restriction.
>
> A few clumsy hacks get rid of the error message, but fail to cause
> xconfig to enforce the limit.
>
> Is there some other way to prohibit modules from being compiled into
> the main kernel?
I think that
depends on m
will do what you want. That's what some ancient PCMCIA drivers
do, as well as the crypto test module.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Tue, May 15, 2007 at 04:41:30PM -0700, Randy Dunlap wrote:
> On Tue, 15 May 2007 16:30:02 -0700 Paul E. McKenney wrote:
>
> > Hello!
> >
> > It would be nice to constrain RCU_TORTURE_TEST to "n" or "m", excluding
> > "y", since "y" gives anti-social results that I have never seen a use
> > for. So I tried adding a "range n m" to the Kconfig.debug entry for
> > RCU_TORTURE_TEST. This gives me the following warning at "make xconfig"
> > time:
> >
> > lib/Kconfig.debug:386:warning: range is only allowed for int or hex symbols
> >
> > and xconfig ignores the restriction.
> >
> > A few clumsy hacks get rid of the error message, but fail to cause
> > xconfig to enforce the limit.
> >
> > Is there some other way to prohibit modules from being compiled into
> > the main kernel?
>
> I think that
> depends on m
> will do what you want. That's what some ancient PCMCIA drivers
> do, as well as the crypto test module.
This indeed works! Thank you!!!
Thanx, Paul
>
> Is there some other way to prohibit modules from being compiled into
> the main kernel?
One way is to use a separate symbol that is not user visible, but depends
on your main symbol and uses default m
(similar to the now infamous CONFIG_SCSI_WAIT_SCAN)
-Andi
Andi Kleen wrote:
> One way is to use a separate symbol that is not user visible, but depends
> on your main symbol and uses default m
>
> (similar to the now infamous CONFIG_SCSI_WAIT_SCAN)
Actually CONFIG_SCSI_WAIT_SCAN should be visible and restricted to m or
n. :-)
--
Stefan Richter
-=====-=-=== -=-= =----
http://arcgraph.de/sr/
On 5/16/07, Stefan Richter <[email protected]> wrote:
> Andi Kleen wrote:
> > One way is to use a separate symbol that is not user visible,
Gargle ... gargle ...
> > but depends on your main symbol
> > and uses default m
Aargh!
Please don't recommend such a hack.
[ Note to LKML archive readers: Andi never said this, you never read this. ]
> > (similar to the now infamous CONFIG_SCSI_WAIT_SCAN)
>
> Actually CONFIG_SCSI_WAIT_SCAN should be visible and restricted to m or
> n. :-)
Actually, SCSI_WAIT_SCAN doesn't want to be a separate module in the
first place :-)
On Wed, May 16, 2007 at 02:18:48PM +0200, Andi Kleen wrote:
>
> >
> > Is there some other way to prohibit modules from being compiled into
> > the main kernel?
>
> One way is to use a separate symbol that is not user visible, but depends
> on your main symbol and uses default m
>
> (similar to the now infamous CONFIG_SCSI_WAIT_SCAN)
Cool!!! Any problem you see with Randy Dunlap's suggestion of simply
adding "depends on m", though?
Thanx, Paul