Hi Greg,
thanks for your feedback! I've updated the document with your suggestions.
On Wed, 2022-04-06 at 20:55 -0400, Greg Troxel wrote:
Some comments from a packager and experience with switching to cmake, some of it ok, some of it bad. I'm trimming stuff I don't have any comments on as I think you have this mostly right.
Thomas Heijligen src@posteo.de writes:
## Platforms to support * Systems * Linux (Distros / ChromeOS)
Long-Term Stable is a real issue. It's not really reasonable for people to expect to build new flashrom with ancient tools, on a system where they have chosen to run old code to get some kind of stability. Yet people routinely demand that they be able to build the latest release of Foo using an LTS with compiler, autoconf, cmake and the like from 5 years ago. They want new Foo, but suggesting they get non-crufty tools and they act like upstream is being unreasonable because their LTS is "supported". My respones is "well, tell RHEL/Ubuntu to do it for you and stop demanding I do it".
The current policy with the Makefile is to stay backwards compatible. Since meson is not this long around we have to choose a way to go. Personally I had the problem that my system meson from a rolling release distro was to old to build a project from master branch.
----------------------------------------------------------------------- ## Open questions * System requirements * How long should we support systems / libraries? * The Makefile supports really old systems in theory (not tested) * Our dependencies are quite stable (libpci, libusb1, …) * Should we support systems until their EOL? What's with LTS systems? * Long-Term stable may a issue, as wee need workarounds on our side for older versions * What should be the minimum required version of meson? * How to find a compromise to satisfy all users of flashrom? -----------------------------------------------------------------------
* SunOS / Solaris / the current version of it
There are two worlds: Oracle Solaris and illumos (OmniOS, OpenIndiana, and more). Probably doesn't need specific code for both, but good to be aware.
I didn't know the exact difference sice all systems get build as SunOS ----------------------------------------------------------------------- ## Platforms to support * Systems * SunOS, Solaris / illumos, OmniOS, OpenIndiana -----------------------------------------------------------------------
* Architectures * X86 * ARM * MIPS * POWER x86 supports port I/O (mostly relevant to PCI), others may through MMIO emulation
I guess that's an interesting question. I'm not clear on the full set of interfaces for reading/writing. But really the code should be portable to any reasonable CPU. x86, arm, mips, and ppc are really pairs of CPU architectures, each of which has a 32-bit and a 64-bit variant. And it's a pretty short list; NetBSD also runs on sparc, sparc64, m68k, and less sensible for flashrom, vax, alpha, ia64, and hppa. And, RISC-V is coming and I expect it to appear whereever arm64 does in a few years.
There is code that works only on one architecture, like x86 port I/O or msr access. Some architectures need a sync call fall mmio. When trying flashrom on a unsupported architecture this may result in unwanted behavior.
----------------------------------------------------------------------- ## Platforms to support * Architectures (32 & 64bit sets) * x86 (much exclusive codes paths) * mips (some exclusive mips code paths, processor_enable.c) * ppc (single exclusive code path, hwaccess_physmap.c) * arm * sparc (single exclusive codepath, hwaccess_physmap.c) * alpha * hppa * m68k * riscv * sh * s390 * arc * (cross compiling architectures)
## Tasks * Make sure the mmio sync is implemented for all supported architectures -----------------------------------------------------------------------
In requirements, you left out (but I know you are thinking of cross):
cross compilation
Almost entirely, switch code on/off by feature tests, and attempt to drive the number of "#ifdef FooOS" to zero. It's not doable entirely, but autoconf got this right and a lot of things that claim they are better do not.
----------------------------------------------------------------------- ## Tasks * Reduce the number of #ifdef by moving the decision to the build system -----------------------------------------------------------------------
* Write documentation * Build instructions for all platforms
Aside from windows, they really should not be different.
----------------------------------------------------------------------- ## Tasks * Write documentation * Build instructions for all platforms (especially for cross compiling only targets) -----------------------------------------------------------------------
## Open questions * System requirements * How long should we support systems / libraries? * As long as they have vendor support
That's very messy. On one hand if vendors (== "os maintainers") drop support early, it's good to go back slightly further. On the other, if someone decides to freeze code in 2020 and maintain it with *security patches only* for 10 years, then I think a reasonable response is "if you want to run code from 2020 with only security patches, good luck
the license gives you the freedom to do that, but it's not our obligation to do work to make that be easy". Note that such people are welcome to keep running the flashrom version from 2020; that is after all what they chose to do.
Yes, I sound cranky, but the crankiness comes from maintaining unison.
* What should be the minimum required version of meson? * The version of the oldest supported system.
Again, same issue.
Same as above
* Build dependencies * Can we fetch dependencies like cmocka? This makes building for some systems easier
No, you can't fetch anything at build time. Packaging systems view that as a bug. It means you can't build on a machine not on the internet. Yes, I have built lots of packages on a disconnected machine after fetching their releaes tarballs and transferring on CDROM, and it almost entirely works.
So options are:
if you want to depend on something, list in in the README and demand that the user have it installed already. If it doesn't already exist as a package in most packaging systems, that's a clue you shouldn't use it.
vendor it in. But you really shouldn't do this, because then when there is a security release of that included code, you really need to have a new micro very fast, and I'll pick 7 days out of a hat.
Sorry, that may worded inaccurately. For packaging it is realy bad to fetch things from the internet. For systems without a package manager this may be realy helpfull. Fetching things from the internet should deactivatable and only used as fallback.
----------------------------------------------------------------------- ## Open questions * Build dependencies * Can we have a fallback to fetch dependencies? (like with cmocka currently) * When available use the system version, else fall back to fetch from online * Does this work for all our dependencies? * Nice for systems without package manager (Windows, djgpp-dos- cross) * When packaging you can’t fetch anything from online * Option to enable / disable this -----------------------------------------------------------------------
* Shared libflashrom * How to handle versioning?
shared library major/minor is pretty well established (major bump on ABI break, minor bump on ABI addition, and try really hard not to break the ABI). I'm not sure what the question is.
The API of libflashrom is not stable nor feature complete, but we have users of the shared library with the unstable API.
----------------------------------------------------------------------- ## Open questions * shared libflashrom with no stable API * How to handle versioning of it? * For stable API there is a well established system major.minor.patch * What to do until the API is stable? * When is the API stable enough? * Use major = 0 until it’s stable and increment minor on each change -----------------------------------------------------------------------
## Sequence for switching the primary build system * Meson is feature equivalente with the Makefile * Switch to meson as default build system, update the documentation * Make a release with meson as the primary build system, keep the Makefile for legacy compatible. * Drop the Makefile * Drop dead code from Makefile only based option
Understand that packagers will need to put in work to switch, they aren't usually paid 40h/week to package, and they don't think flashrom is the most important thing in the world. So what you said means that they have the time between the release with meson documented as primary and the release w/o Makefile. If meson behaves as well as meson proponents say (which given what I've heard about the plan seems likely), that will be only a few hours or less.
As a nit there should be at least 2 months between "release where meson is primary and no significant meson problems are reported" and "release w/o Makefile".
The release cycles of flashrom are quite irregular and slow. There should be enough time to adopt. The release brach should also keep the old Makefile. Only the release after that will drop the Makefile.
----------------------------------------------------------------------- ## Sequence for switching the primary build system * Meson is feature equivalente with the Makefile (master branch) * Switch to meson as default build system, update the documentation (master branch) * Beta phase to get feedback (2 month or more) (master release branch) * Make a release with meson as the primary build system, keep the Makefile for legacy compatible. (release branch) * Drop the Makefile (master branch only) * Drop dead code from Makefile only based option (master branch only) -----------------------------------------------------------------------
5. Define what testing means. Should we run flashrom or flash something? How do we check that meson supports the system? 1. Build and run unit tests. 2. Run the binary to see that it works 3. Great thing would be to use one (or more :)) programmer. Maybe just dummy?
I think you need to at least read a ROM and compare, and really flash an update. But that's only when other tests are all happy and less often.
I've moved the testing topic to "Further Projects". This is important, but to much and not quite the scope of this project.
Hope this helps.
This was great help. Thanks a lot!
-- Thomas
flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-leave@flashrom.org