Re: Rust kernel policy

["Martin K. Petersen" <martin.petersen@oracle.com>]

James,

>> I like using cleanup attributes for some error handling. However, I'm
>> finding that in many cases I want to do a bit more than a simple
>> kfree(). And at that point things get syntactically messy in the
>> variable declarations and harder to read than just doing a classic
>> goto style unwind.
>
> So the way systemd solves this is that they define a whole bunch of
> _cleanup_<type>_ annotations which encode the additional logic.  It
> does mean you need a globally defined function for each cleanup type,
> but judicious use of cleanup types seems to mean they only have a few
> dozen of these.

Yep, I'm just observing that - at least for the project where I most
recently used this - the attribute boilerplate stuff got in the way of
the code being readable.

In addition, the most common cleanup scenario for me has been "twiddle
something and then free" for a series of one-off local variables for
which it makes no sense to have a type-specific definition.

The proposed "defer" approach is a bit more flexible:

  https://gustedt.wordpress.com/2025/01/06/simple-defer-ready-to-use/

I have experimented at length with __attribute__(__cleanup__) and defer.
I am sympathetic to the idea, but none of the approaches I tried lead to
code that was particularly pleasing to my eyes.

I find that mixing regular code flow and error handling by interleaving
defer statements throughout the function often makes the regular code
path harder to follow. Once a cleanup becomes more than a simple free()
in the variable declaration, the mixing of happy and unhappy code can
make things quite muddy.

Note that none of this should be seen as opposition to using cleanup or
defer. I use them both where applicable. I am just saying I was more
enthusiastic until I actually started using them. After converting a
fairly large code base, I ended up reverting to a classic unroll in
several places because I found it was much clearer.

-- 
Martin K. Petersen	Oracle Linux Engineering