Make powerpc use MAXARGS instead of hardcoding '10'

[trasz]

Summary

Make powerpc use MAXARGS instead of hardcoding '10'. Note that
MAXARGS is 8; no idea where the 10 came from.

[bdragon]

It comes from the Book-E syscall. See the changes to sys/powerpc/booke/trap.c in rS208453 -- it uses two more args than AIM.

As to whether THAT was correct at the time, I am unsure.

[bdragon]

It does look like it was intentionally done at the time, due to there being code that explicitly copies in more arguments from the user stack frame if sy_narg goes over 8.

[bdragon]

and indeed, the code to do so still exists in cpu_fetch_syscall_args().

So, despite there only being 8 actual registers involved, the system still supports more parameters than that using the normal rules for storing overflow parameters in the stack frame.

[bdragon]

I believe the necessity for this is for SYS___syscall. It burns *two* registers on 32-bit for alignment reasons.

[trasz]

In my understanding sy_narg cannot be more than MAXARGS, which is generally 8. I'd say it's highly unlikely we'll ever support more syscall arguments, even now there are at most 7. But to the point: SYS__syscall indeed looks like wasting two registers, but I don't see how it affects struct syscall_args: the array contents are the arguments to MI syscall functions (eg sys_open()). In other words, SYS__syscall affects how the arguments are passed from userspace, but not how they get passed from cpu_fetch_syscall_args() to the actual sys_whatever(). Right?

[trasz]

This comment was removed by trasz.

[bdragon]

I think you might be right, at most args[6] and args[7] would be subject to being pulled from the argument overflow area of the stack frame rather than the registers, assuming an 8 parameter syscall going through SYS___syscall, and they are filled in to args at their final positions instead of their raw positions.

[jhibbits]

Seems fine to me. It's consistent with all other archs.

[bdragon]

No complaints here.