prison_owns_vnet taking a struct prison makes sense

There's a general trend in the "prison can do this thing" functions that they all take a ucred. One the one hand it seems reasonable that they would all take a struct prison instead, but is there a particular reason to break the trend for this case?

In D51524#1176859, @jamie wrote:

There's a general trend in the "prison can do this thing" functions that they all take a ucred. One the one hand it seems reasonable that they would all take a struct prison instead, but is there a particular reason to break the trend for this case?

D51525 and D51526 both require this change. In particular, I want to be able to determine, from a jail PR_METHOD_REMOVE callback, whether the jail belongs to its own VNET. There, there is no credential I can use.

I could instead add an alternative function or even just an inline "is PR_VNET set" check.

In D51524#1176932, @jamie wrote:

In D51524#1176869, @markj wrote:

I could instead add an alternative function or even just an inline "is PR_VNET set" check.

I'm fine with the change, just didn't have the context.

I actually like the idea of the simple inline check, since I generally get annoyed by abstractions that are no easier to remember than the thing they're abstracting. But since that functions does exist, it seems best to just twist it a little to meet your needs.

I'd argue that using prison_owns_vnet() is every so slightly clearer than checking PR_VNET, at least to someone who isn't too familiar with jail internals. I had to take a minute to check that PR_VNET being set really does mean that the jail owns its VNET, and not just that the jail belongs to a non-default VNET.