Refactor: Imports structure

[mbssrc]

Description of changes

Make more flake-modules, and various changes. To be discussed.

Checklist for things done

• Summary of the proposed changes in the PR description
• More detailed description in the commit message(s)
• Commits are squashed into relevant entities - avoid a lot of minimal dev time commits in the PR
• Contribution guidelines followed
• Ghaf documentation updated with the commit - https://tiiuae.github.io/ghaf/
• PR linked to architecture documentation and requirement(s) (ticket id)
• Test procedure described (or includes tests). Select one or more:
  • Tested on Lenovo X1 x86_64
  • Tested on Jetson Orin NX or AGX aarch64
  • Tested on Polarfire riscv64
• Author has run make-checks and it passes
• All automatic Github Action checks pass - see actions
• Author has added reviewers and removed PR draft status
• Change requires full re-installation
• Change can be updated with nixos-rebuild ... switch

Instructions for Testing

• List all targets that this applies to:
  • AGX
  • NX
  • x86_64
• Is this a new feature
  • List the test steps to verify:
• If it is an improvement how does it impact existing functionality?

[brianmcgillion]

do not add disko here it is not used in all laptop configurations only in the debug ones

[mbssrc]

as of now (pre PR#1074), it is. same as current implementation with commonModules. also, the enable flag is now in reference profile, so it can be turned on/off in the settings

[humaidq-tii]

Would it cause issues if the disko module is not imported at all? Since the target in #1074 would not build properly, conflicting options with disko if imported.

[mbssrc]

My thinking here is that we sync the targets identifier and the conditional modules definition, i.e. target = hw + platform profile identifier, with platform profile {mvp, ...} + {debug, release, any-other}. This would allow to move towards a generic interface for a laptop-builder and target definition. Not quite sure if a disk layout configuration at this level is necessary? And could we not just make the namespaces not overlapping? Then, instead of relying on conditional imports we control it via config settings, e.g. using -debug/release or even additional flags

[brianmcgillion]

there are a min of 3 levels of config that need to be supported.

1. the hardware config (e.g. x1)
2. the profile config (e.g. mvp)
3. the target config ( with customizations available specific to this target definition)

The current laptop targets/laptop/flake-module.nix supports this.

[humaidq-tii]

Not all targets would use disko especially with #1074, even the disko module shouldn't be included as that would conflict with certain options.

[humaidq-tii]

Would it cause issues if the disko module is not imported at all? Since the target in #1074 would not build properly, conflicting options with disko if imported.