Skip to content

Conversation

fjmolinas
Copy link
Contributor

Contribution description

This PR looks to extend the granularity of auto_init MODULES. Currently only auto_init is a DEFAULT_MODULE which means its the only one that can be disabled, which translates into, get everything or nothing. As a user I could want to only deactivate one of this auto_init modules and keep the rest (for examples in our tests).

This PR wan't to achieve this by declaring all curent cases of USEMODULE += auto_init_% as DEFAULT_MODULE += auto_init_%, it also by default declares all auto_init_% as pseudomodules (except for those that are not).

As an example I add an auto_init_xtimer module and changes the gauards in auto_init.c to reflect this. IMO this could be done for all modules in auto_init, but that would mean a lot of changes, so maybe better to introduce when needed?

Testing procedure

  • green murdock

  • try disabling a module, I added a #error in:

#ifdef MODULE_AUTO_INIT_XTIMER
    #error
    DEBUG("Auto init xtimer module.\n");
    xtimer_init();
#endif

and compiled with and without disabling DISABLE_MODULE+=auto_init_xtimer make -C tests/xtimer_usleep

Issues/PRs references

Though of this because of #13052

@fjmolinas fjmolinas added Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR labels Jan 11, 2020
@fjmolinas fjmolinas added CI: disable test cache If set, CI will always run all tests regardless of whether they have been run successfully before CI: run tests If set, CI server will run tests on hardware for the labeled PR CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Jan 16, 2020
@fjmolinas
Copy link
Contributor Author

I removed now all DISABLE_AUTO_INIT I checked them all and replaced the ones that where needed by specific ones. I only left minimal and unittests. Unitests could probably also be removed by adding disable to every sub-test.

@fjmolinas
Copy link
Contributor Author

Ups I had NO_PSEUDOMODULES += auto_init_usb instead of NO_PSEUDOMODULES += auto_init_usbusm i'll push the fix once the build ends.

@fjmolinas
Copy link
Contributor Author

BTW this should wait for the release to be over.

@fjmolinas fjmolinas force-pushed the pr_auto_init_default_modules branch 2 times, most recently from 6a4a3e8 to 4d5ddfb Compare January 16, 2020 12:38
@fjmolinas
Copy link
Contributor Author

Rebased.

@fjmolinas fjmolinas added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Jan 16, 2020
@fjmolinas
Copy link
Contributor Author

I'll also add drivers/periph_common/init.c since #11026 mentioned it being a nuisance for modular design, that way it can be disabled.

@fjmolinas
Copy link
Contributor Author

I'll also add drivers/periph_common/init.c since #11026 mentioned it being a nuisance for modular design, that way it can be disabled.

I'll do a separate PR for this, murdock already on this one so it should be ok as is,

Makefile.dep Outdated
@@ -1038,6 +1036,64 @@ ifneq (,$(filter devfs_random,$(USEMODULE)))
USEMODULE += random
endif

ifneq (,$(filter auto_init,$(USEMODULE)))
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to move this to a separate file?

Makefile.dep Outdated
@@ -1038,6 +1036,64 @@ ifneq (,$(filter devfs_random,$(USEMODULE)))
USEMODULE += random
endif

ifneq (,$(filter auto_init,$(USEMODULE)))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would make sense to turn this into a loop.
Something like

HAS_AUTO_INIT += foo \ 
                                  bar \
                                  #
ifneq (,$(filter auto_init,$(USEMODULE)))
 DEFAULT_MODULE += $(patsubst %,auto_init_%,$(filter $(HAS_AUTO_INIT),$(USEMODULE))
endif

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe additionally filter on DISABLED_MODULES

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

HAS_AUTO_INIT += foo \ 
                 bar \

where would this be?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in Makefile.dep for now is fine, no?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The alternative would be to have, for every module that uses auto_init, a dependency block:

ifneq (,$(filter foo,$(USEMODULE)))
  ifneq (,$(filter auto_init,$(USEMODULE)))
    DEFAULT_MODULE += auto_init_foo
  endif
endif

This way, the information is "closer" to the module's dependency info.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like the HAS_AUTO_INIT because these function do not allways match a module name which makes it kind of weird. These HAS_AUTO_INIT would IMO have to be in the modules MAKEFILE, but some of these MODULES are not pseudomodules, so it isn't a HAS_AUTO_INIT but use this MODULEs init function in a way, and there isn't a MODULE<->auto_init naming match in all cases.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is what I had initially and changed to a suggestion from @aabadie

hmok, @aabadie, why "later in the file"?

Copy link
Contributor

@aabadie aabadie Feb 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why "later in the file"?

in order to know all modules with potential auto_init support. but since this file is included transitively, this doesn't make much sense.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So which style is prefered @aabadie @kaspar030?

Copy link
Contributor

@kaspar030 kaspar030 Feb 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For me,

ifneq (,$(filter foo,$(USEMODULE)))
    DEFAULT_MODULES += auto_init_foo
   ...
endif

... together with some logic so that if auto_init is disabled, all auto_init_% are also disabled.

@@ -3,6 +3,4 @@ include ../Makefile.tests_common

FEATURES_REQUIRED = periph_rtt

DISABLE_MODULE += auto_init
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be removed this is still called, since init_rtt is not in auto_init

@kaspar030 kaspar030 removed the Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR label Feb 11, 2020
@kaspar030
Copy link
Contributor

I've removed the discussion label, I think there's consensus this is a nice idea.

@fjmolinas fjmolinas added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Feb 12, 2020
@fjmolinas fjmolinas force-pushed the pr_auto_init_default_modules branch from aefb068 to ef76fe4 Compare February 12, 2020 15:10
@fjmolinas
Copy link
Contributor Author

Rebased to fix conflict.

@fjmolinas fjmolinas removed the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Feb 12, 2020
@fjmolinas fjmolinas force-pushed the pr_auto_init_default_modules branch from ef76fe4 to c830260 Compare February 12, 2020 15:50
Declaring all auto_init_% modules as pseudomodules will allow
using auto_init_% modules as modules that can be disabled. This
will give a higher lever of granularity allowing users to not
disable the complete auto_init module but only some of them.
Currently default modules resolution is only performed in
Makefile.include. This avoids DEFAULT_MODULES being declared
in Makefile.dep since they never become USEMODULE.

Duplicate at the end of the dependency resolutiion after recursive
cach of transitive depdencies since at this stage DEFAULT_MODULES
can't and SHOULD NOT trigger depedency resolutions.
Having the modules as DEFAULT_MODULES allows disabling them.
@fjmolinas fjmolinas force-pushed the pr_auto_init_default_modules branch from c830260 to e0855de Compare February 12, 2020 15:51
@fjmolinas fjmolinas added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Feb 12, 2020
@fjmolinas
Copy link
Contributor Author

@kaspar030 @aabadie can you check if all is OK for you, this one diverges quickly.

Copy link
Contributor

@kaspar030 kaspar030 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK. Nice change!

@kaspar030 kaspar030 merged commit aa9388b into RIOT-OS:master Feb 12, 2020
@fjmolinas fjmolinas deleted the pr_auto_init_default_modules branch February 12, 2020 16:23
Comment on lines +258 to +260
DEFAULT_MODULE += auto_init_gnrc_sixlowpan
USEMODULE += sixlowpan
DEFAULT_MODULE += auto_init_gnrc_sixlowpan
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason for adding auto_init_gnrc_sixlowpan twice?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI: disable test cache If set, CI will always run all tests regardless of whether they have been run successfully before CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants