I think checking the exit status [ $? -eq 0 ] is a more robust way to check that this succeeded.

Why run this in the background? If it's because it's a slow operation (I think some interface teardown routines call EPOCH_DRAIN_CALLBACKS()), I'd much rather try to fix that. At least, there should be a comment explaining why.

Is this really needed ? It should be rare that the corresponding driver has been loaded but the creating of interface fails. That should be easily caught by tests incase it happens.

This just checks if the module is loaded, it doesn't load it.

I'm thinking of doing the same here as I did for the python code and just loading the module unconditionally. It's functionally the same as creating an interface anyway. If the module can be loaded but interface can't be created (i.e. someone broke if_epair), as you say, we're going to notice in the tests anyway.

Yeah, I'll change that.

Indeed that. There's no need to wait for the interface destruction so I decided not to.
Removing a single one isn't all that slow, but I wrote this before I added the 'is the module loaded?' check. Given that check we likely will only do the create/destroy dance once.

Arguably it might even be better to do what I did for the python tests, and just load the module rather than try to create an interface.

sorry, why do we do this (in general, as it seem to be contrary to the diff description) and in _check_.. function?

We assume we need if_epair for all vnet tests. In the normal case (i.e. what's default right now) we just automatically load it when we create the first epair interface. That doesn't work in the kyua execenv=jail environment (because we can't load kernel modules from a jail).

We use the existing require_module() code so that we skip the test if the module is not loaded, but first we attempt to load it. That means that in the normal case we'll load the module and satisfy the require_module check. In the execenv=jail case we'll fail to load, but we ignore errors from that. When we hit the require_module check we'll either have the module (because it was loaded before the tests were started) or we'll skip the tests.

I will rename this though, to avoid the confusing _check name.

It turns out that we do need it. kldload -n still fails even if the module is already loaded when it is run from inside a jail.

Arguably that's a bug in kldload(), because all it'd let jails do is figure out if a module is loaded or not, which it can already do with kldstat(). Allowing the no-op kldload() to succeed would make the jail slightly closer to an unjailed system and that can only help more software to run in a jail.

(To be clear: I'm proposing that kldload() ought to just succeed for modules which are already loaded, even when called from within a jail. It should still refuse to actually load new modules from a jail, of course.)