RFC: supporting more models (platforms, board files, support tiers)

[rylos]

synodeb started as "Debian on my DS923+", and it is getting contributions for other models
(thanks @luuvasara for the DS2415+/DX1215 work in #1-#5). Before merging any of it, I'd like to
agree on a structure that can take many models and expansion units without one maintainer having
to own (and test) all of them. Comments welcome; the layout below is a proposal.

Platforms, not models

Synology reuses a few platforms across many models (r1000: DS923+/DS723+/DS1522+, avoton:
DS2415+/DS1815+…). Code is grouped by platform:

platforms/<platform>/kernel/      drivers and patches (kernel/src layout), DMI/PCI gated
platforms/<platform>/synohwd.py   front-panel microcontroller board for synohwd
platforms/<platform>/pkg/         files of the synology-<platform> package
boards/<model>.conf               one data file per model (e.g. boards/ds923plus.conf)
expansions/<unit>/                expansion units (DX517, DX1215…)

A board file holds what is specific to one model: DSM name, platform, DOM identity (FAT volume
id, ext2 UUID, partition sizes), console, bays, boot method (direct or stage1). The setup
script, the installer, the package and synohwd all read it. A new model of a supported platform
is just a board file.

One kernel per series

Two series, as today: longterm (6.18.y, default) and stable (newest x.y). All platform
drivers are built as modules into the same kernel and bind only to their hardware, so the number
of builds does not grow with the number of models. The kernel suffix becomes -synology
(transitional packages keep -ds923 systems updating).

Support tiers

tier	meaning
supported	a maintainer owns the hardware and tests every release
community	tested on hardware when added; a failure does not block a release
wip	builds, not yet tested on hardware

A model without a maintainer drops a tier, then is removed.

Maintainers and review

• CODEOWNERS per platform: platform maintainers review their own directories; core changes
  (installer, DOM handling, kernel series, apt repository, CI) are reviewed by the core
  maintainer.
• CONTRIBUTING.md: hardware test evidence in the PR (boot log on the real unit), small PRs, no
  Synology binaries or code, patches to shared kernel code (libata, md…) also sent upstream.
• CI builds every platform on every PR.

Boot methods

direct (today: kernel and initrd on the DOM, DEBIAN/DEBIAN_OLD) stays the default.
stage1 (#4: a small loader written to the DOM once, the real kernel started from the disks
with kexec) becomes an option for models whose DOM needs it, or for users who prefer fewer DOM
writes, once it has a fallback to the previous kernel and has been tested on a DS923+.

Plan

1. Restructure the repository on a branch with no change for the DS923+ (same packages, same
   behaviour, existing tests and an install/upgrade test in a VM).
2. Port the DS2415+ (avoton, community tier) onto it as the first second platform; synodeb-setup.sh: model profile instead of DS923+ hard-codes #2-kernel: patch 0009, PMP vendor registers from a quiet EH round #5 are
   reworked there.
3. Possibly move to a synodeb GitHub organization later.

Thoughts on the layout, the names, or anything that would make porting your model easier?

[n7en]

I just ran across this, and I want to put debian on my 1522+.