Re: Feedback sought: can we drop cgroupv1 support soon?

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Fr, 22.07.22 12:37, Wols Lists (antlists@xxxxxxxxxxxxxxx) wrote:

> On 22/07/2022 11:15, Lennart Poettering wrote:
> > > I guess that would mean holding on to cgroup1 support until EOY 2023
> > > or thereabout?
>
> > That does sound OK to me. We can mark it deprecated before though,
> > i.e. generate warnings, and remove it from docs, as long as the actual
> > code stays around until then.
>
> You've probably thought of this sort of thing already, but can you wrap all
> v1-specific code in #ifdefs? Especially if it's inside an if block, the
> compiler can then optimise the test away if you compile with that set to
> false.
>
> Upstream can then set the default to false, while continuing to support it,
> but it will then become more and more a conscious effort on the part of
> downstream to keep it working.
>
> Once it's visibly bit-rotting you can dump it :-)

The goal really is to reduce code size, not to increase it further by
having to maintain a ton of ifdeffery all over the place.

we generally frown on ifdeffery in "main" code aleady, i.e. we try to
isolate ifdeffery into "library" calls that hide it internally, and then
return EOPNOTSUPP if somethings is compiled out. That way the "main"
code can then treat compiled out stuff via usual error handling,
greatly simplifying conditionalizations and the combinatorial
explosion from having many optional deps.

ifdeffery comes at a price, and is very hard to test for (because CIs
do not test in all combinations of present and absent optional deps),
hence the goal should be to minimize, isolate it, not emphasize it and
sprinkle it over the whole codebase as if it was candy.

Lennart

--
Lennart Poettering, Berlin