The test is limited to be compiled as a module. There's no technical
reason for it. Now that the test bears performance benchmark, it would
be reasonable to allow running it at kernel load time, before userspace
starts, to reduce possible jitter.
Signed-off-by: Yury Norov <yury.norov@gmail.com>
---
lib/Kconfig.debug | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c63a5fbf1f1c..fc8fe1ea5b49 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2436,7 +2436,6 @@ config TEST_LKM
config TEST_BITOPS
tristate "Test module for compilation of bitops operations"
- depends on m
help
This builds the "test_bitops" module that is much like the
TEST_LKM module except that it does a basic exercise of the
--
2.40.1
On Thu, May 02, 2024 at 04:32:01PM -0700, Yury Norov wrote: > The test is limited to be compiled as a module. There's no technical > reason for it. Now that the test bears performance benchmark, it would > be reasonable to allow running it at kernel load time, before userspace > starts, to reduce possible jitter. > > Signed-off-by: Yury Norov <yury.norov@gmail.com> > --- > lib/Kconfig.debug | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index c63a5fbf1f1c..fc8fe1ea5b49 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -2436,7 +2436,6 @@ config TEST_LKM > > config TEST_BITOPS > tristate "Test module for compilation of bitops operations" > - depends on m Perhaps it would be better to modify the description in the following help section at the same time? Reviewed-by: Kuan-Wei Chiu <visitorckw@gmail.com> > help > This builds the "test_bitops" module that is much like the > TEST_LKM module except that it does a basic exercise of the > -- > 2.40.1 >
On Fri, May 03, 2024 at 10:00:07AM +0800, Kuan-Wei Chiu wrote: > On Thu, May 02, 2024 at 04:32:01PM -0700, Yury Norov wrote: > > The test is limited to be compiled as a module. There's no technical > > reason for it. Now that the test bears performance benchmark, it would > > be reasonable to allow running it at kernel load time, before userspace > > starts, to reduce possible jitter. > > > > Signed-off-by: Yury Norov <yury.norov@gmail.com> > > --- > > lib/Kconfig.debug | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > > index c63a5fbf1f1c..fc8fe1ea5b49 100644 > > --- a/lib/Kconfig.debug > > +++ b/lib/Kconfig.debug > > @@ -2436,7 +2436,6 @@ config TEST_LKM > > > > config TEST_BITOPS > > tristate "Test module for compilation of bitops operations" > > - depends on m > > > Perhaps it would be better to modify the description in the following > help section at the same time? What exactly you want to change? > Reviewed-by: Kuan-Wei Chiu <visitorckw@gmail.com> > > > help > > This builds the "test_bitops" module that is much like the > > TEST_LKM module except that it does a basic exercise of the > > -- > > 2.40.1 > >
On Thu, May 02, 2024 at 07:14:10PM -0700, Yury Norov wrote: > On Fri, May 03, 2024 at 10:00:07AM +0800, Kuan-Wei Chiu wrote: > > On Thu, May 02, 2024 at 04:32:01PM -0700, Yury Norov wrote: > > > The test is limited to be compiled as a module. There's no technical > > > reason for it. Now that the test bears performance benchmark, it would > > > be reasonable to allow running it at kernel load time, before userspace > > > starts, to reduce possible jitter. > > > > > > Signed-off-by: Yury Norov <yury.norov@gmail.com> > > > --- > > > lib/Kconfig.debug | 1 - > > > 1 file changed, 1 deletion(-) > > > > > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > > > index c63a5fbf1f1c..fc8fe1ea5b49 100644 > > > --- a/lib/Kconfig.debug > > > +++ b/lib/Kconfig.debug > > > @@ -2436,7 +2436,6 @@ config TEST_LKM > > > > > > config TEST_BITOPS > > > tristate "Test module for compilation of bitops operations" > > > - depends on m > > > > > > Perhaps it would be better to modify the description in the following > > help section at the same time? > > What exactly you want to change? > It seems to me that the entire description is written specifically for the module. For instance, "doesn't run or load unless explicitly requested by name. for example: modprobe test_bitops." In my view, this description is no longer accurate. Regards, Kuan-Wei > > Reviewed-by: Kuan-Wei Chiu <visitorckw@gmail.com> > > > > > help > > > This builds the "test_bitops" module that is much like the > > > TEST_LKM module except that it does a basic exercise of the > > > -- > > > 2.40.1 > > >
On Fri, May 03, 2024 at 10:24:23AM +0800, Kuan-Wei Chiu wrote: > On Thu, May 02, 2024 at 07:14:10PM -0700, Yury Norov wrote: > > On Fri, May 03, 2024 at 10:00:07AM +0800, Kuan-Wei Chiu wrote: > > > On Thu, May 02, 2024 at 04:32:01PM -0700, Yury Norov wrote: > > > > The test is limited to be compiled as a module. There's no technical > > > > reason for it. Now that the test bears performance benchmark, it would > > > > be reasonable to allow running it at kernel load time, before userspace > > > > starts, to reduce possible jitter. > > > > > > > > Signed-off-by: Yury Norov <yury.norov@gmail.com> > > > > --- > > > > lib/Kconfig.debug | 1 - > > > > 1 file changed, 1 deletion(-) > > > > > > > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > > > > index c63a5fbf1f1c..fc8fe1ea5b49 100644 > > > > --- a/lib/Kconfig.debug > > > > +++ b/lib/Kconfig.debug > > > > @@ -2436,7 +2436,6 @@ config TEST_LKM > > > > > > > > config TEST_BITOPS > > > > tristate "Test module for compilation of bitops operations" > > > > - depends on m > > > > > > > > > Perhaps it would be better to modify the description in the following > > > help section at the same time? > > > > What exactly you want to change? > > > It seems to me that the entire description is written specifically for > the module. For instance, "doesn't run or load unless explicitly > requested by name. for example: modprobe test_bitops." In my view, this > description is no longer accurate. In-kernel module is still module. Everything is the same as for .ko, except that it's loaded automatically and earlier for you. To me this part of the description is correct. If you feel it should be reworded - feel free to submit a patch. Now that we add more functionality in that, it's probably worth to do. Not in this series, though. Thanks, Yury
On Fri, May 03, 2024 at 08:13:05AM -0700, Yury Norov wrote: > On Fri, May 03, 2024 at 10:24:23AM +0800, Kuan-Wei Chiu wrote: > > On Thu, May 02, 2024 at 07:14:10PM -0700, Yury Norov wrote: > > > On Fri, May 03, 2024 at 10:00:07AM +0800, Kuan-Wei Chiu wrote: > > > > On Thu, May 02, 2024 at 04:32:01PM -0700, Yury Norov wrote: > > > > > The test is limited to be compiled as a module. There's no technical > > > > > reason for it. Now that the test bears performance benchmark, it would > > > > > be reasonable to allow running it at kernel load time, before userspace > > > > > starts, to reduce possible jitter. > > > > > > > > > > Signed-off-by: Yury Norov <yury.norov@gmail.com> > > > > > --- > > > > > lib/Kconfig.debug | 1 - > > > > > 1 file changed, 1 deletion(-) > > > > > > > > > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > > > > > index c63a5fbf1f1c..fc8fe1ea5b49 100644 > > > > > --- a/lib/Kconfig.debug > > > > > +++ b/lib/Kconfig.debug > > > > > @@ -2436,7 +2436,6 @@ config TEST_LKM > > > > > > > > > > config TEST_BITOPS > > > > > tristate "Test module for compilation of bitops operations" > > > > > - depends on m > > > > > > > > > > > > Perhaps it would be better to modify the description in the following > > > > help section at the same time? > > > > > > What exactly you want to change? > > > > > It seems to me that the entire description is written specifically for > > the module. For instance, "doesn't run or load unless explicitly > > requested by name. for example: modprobe test_bitops." In my view, this > > description is no longer accurate. > > In-kernel module is still module. Everything is the same as for .ko, > except that it's loaded automatically and earlier for you. To me this > part of the description is correct. > > If you feel it should be reworded - feel free to submit a patch. Now > that we add more functionality in that, it's probably worth to do. Not > in this series, though. > > Thanks, > Yury Got it, thank you for the explanation! :) Regards, Kuan-Wei
© 2016 - 2025 Red Hat, Inc.