[LTP] [RFC] Getting rid of cleanup parameter

[Jiri Jaburek]

On 11/11/2015 02:30 PM, Cyril Hrubis wrote:
> Hi!
>> Just thinking loud, how this would work:
>>
>> Is the scope of cleanup set with tst_set_cleanup() going to be per process?
>> For example: If I call tst_set_cleanup() and then fork couple children,
>> will they automatically ignore cleanup function set in parent?
> 
> It has to be per process, since othewise we would have the callback
> called twice problem again. I.e. the callback set in test setup() would
> be executed only if tst_* call that caused exit was called from the same
> process it has been set up.
> 
>> Can I use tst_set_cleanup() in child process to setup child-specific
>> cleanup function?
> 
> Currently I would do it so that only the main test process can setup the
> callback in order to make it simpler. Since so far I haven't found a
> situation where the parent process cannot easily cleanup after it's
> children and doing cleanup once decreases the possibility of races in
> concurently executed cleanups. Imaginge 100 children cleaning after
> themselves, it's easy to mess up when 100 cleanup functions are running
> at the same time.
> 
> But if you found good usecase we may also allow per-child cleanups.

This may be the case when a test spawns multiple children to do the
testing in parallel, with the children creating shared resources of
unpredictable names/references (so the cleanup cannot be done from
the parent).

I currently cannot think of any such resource,

 * files can use tmpdir, removed recursively from parent
 * spawned processes can be walked from the parent
 * losetup-created devices can have a common prefix
 * IPC shared resources can be pre-created by the parent
   (or be found via a unique key or a dedicated unix user)
 * linux namespaces die automatically with the children
 * ...

The general pattern is that the parent is always able to somehow use
an identifier common for all children or pre-create the resources for
them, collecting a list to be used for cleanup.

However it would be good to keep the use case in mind for the future.

Regarding tst_set_cleanup() - if it hooks the cleanup function into
signal handlers as well, it will need to be called before sigaction
setup in signal-testing tests. Nothing extraordinary, I guess, but
still something to note.

About shell tests - maybe something similar would be useful, for
consistency (same function name) as well as signal handling (trap)
in shells that support it. Again - same signal handling limitations
apply (if test re-defines trap, it may be an issue).

> 
>>> When the cleanup
>>> function was set with this interface the cleanup paramter for all
>>> functions would be ignored (we may create static inline wrappers that
>>> sets it to NULL to be used from new code).
>>
>> And perhaps trigger a warning/TBROK if user tries to pass non-NULL
>> value while he's using the new tst_set_cleanup() approach.
> 
> Yep.
>