fspacectl: remove unneeded freebsd32 wrapper

[brooks]

Summary

fspacectl(2) does not require special handling on freebsd32. The
presence of off_t in a struct does not cause it's size to change
between the native ABI and the 32-bit ABI supported by freebsd32
because off_t is always int64_t on BSD systems. Situations requiring
special handling may arise for i386 if and off_t is proceeded by an
8-byte aligned int, but that situation does not appaly. Further, byte
order only requires handling for paired argument or return registers.

[kib]

Well, this makes kern_fspacectl() useless and not providing the expectation for kern_* that arguments are already in the KVA, isn't it?

[brooks]

@khng points out that rqsr won't ever be NULL in kern_fspacectl. I was misled by the if (rqsr == NULL) that should have been a KASSERT (or nonexistent). I'll update the review shortly.

[brooks]

In D32994#745048, @kib wrote:

Well, this makes kern_fspacectl() useless and not providing the expectation for kern_* that arguments are already in the KVA, isn't it?

I'd prefer to keep kern_fspacectl() as I need it in CheriBSD. I will make it static so it will have zero cost in practice.

[kib]

In D32994#745062, @brooks wrote:

In D32994#745048, @kib wrote:

Well, this makes kern_fspacectl() useless and not providing the expectation for kern_* that arguments are already in the KVA, isn't it?

I'd prefer to keep kern_fspacectl() as I need it in CheriBSD. I will make it static so it will have zero cost in practice.

I mean keep kern_, but do copyin/out in sys_.

[brooks]

In D32994#745067, @kib wrote:

In D32994#745062, @brooks wrote:

In D32994#745048, @kib wrote:

Well, this makes kern_fspacectl() useless and not providing the expectation for kern_* that arguments are already in the KVA, isn't it?

I'd prefer to keep kern_fspacectl() as I need it in CheriBSD. I will make it static so it will have zero cost in practice.

I mean keep kern_, but do copyin/out in sys_.

I don't think that's an expectation of kern_ functions. It's sometimes the desired interface to allow thunking (e.g. for linux or freebsd32), but it's not a consistent requirement.

In this case I'm not convinced we should be copying out unless we've called fo_fspacectl, but I could well be wrong there.

Given that I was wrong about the stack leak, I'd be fine dropping the diff to sys_generic.c entirely and leaving that part alone.

[khng]

In D32994#745078, @brooks wrote:

I don't think that's an expectation of kern_ functions. It's sometimes the desired interface to allow thunking (e.g. for linux or freebsd32), but it's not a consistent requirement.

It is actually my plan to implement Linuxulator's fallocate(2) with a call to fspacectl as well.

[brooks]

• Only remove freebsd32 bits

[emaste]

Situations requiring
special handling may arise for i386 if and off_t is proceeded by an
8-byte aligned int, but that situation does not appaly.

I was a bit confused at first by this statement - I think it is probably worth including, but maybe make it stand apart from the main part of the message or make it explicitly parenthetical or so?

Fixes: 0dc332bff200c