Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • C cmsgemos
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 100
    • Issues 100
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 14
    • Merge requests 14
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • cmsgemonline
  • gem-daq
  • cmsgemos
  • Issues
  • #45

Closed
Open
Created Apr 30, 2020 by Louis Moureaux@lmoureauDeveloper

Define hardware tree iteration order

Summary

The initial revision of the hardware tree core classes (#40 (closed)) will not have an enforced iteration order. There is however a general consensus that iteration order should be predictable. There will be two levels of sorting: between types and within types. So one can have gbt gbt vfat vfat vfat but not gbt vfat vfat gbt vfat.

The order needs be defined and the core classes need be modified to enforce it.

Assignee
Assign to
Time tracking