Re: [PATCH] arch: avr32: add dummy syscalls

[Al Viro]

On Mon, Feb 04, 2013 at 12:30:47AM +0000, Al Viro wrote:
> On Mon, Feb 04, 2013 at 12:10:55AM +0000, Al Viro wrote:
> > On Sun, Jan 27, 2013 at 09:39:54PM +0100, Hans-Christian Egtvedt wrote:
> > > > If you are OK with going that way, I could probably put together patches doing
> > > > just that.  Note that for rt_sigsuspend/rt_sigreturn/sigaltstack the wrappers
> > > > are not needed at all - they can just use current_pt_regs() in syscall body.
> > > > IOW, all of syscall-stubs.S could be killed.
> > > 
> > > Nice, could you put together the preprocessor stuff in a patch? It would be
> > > great to not having to write a re-occuring stub for each syscall that has 6+
> > > arguments.
> > > 
> > > Thanks for looking at this.
> > 
> > Apologies about the delay...  One question: what's the AVR32 C ABI for
> > passing 64bit arguments?  The tricky bugger is sys_sync_file_range();
> > it takes (s32, s64, s64, u32) as arguments and if not any pair of
> > registers can be used to pass 64bit value, we have more serious trouble
> > there...
> 
> BTW, it's worse: both fadivse64 and fadvise64_64 are wired, neither of them
> has a wrapper and arguments are (s32, s64, u32, s32) and (s32, s64, s64, s32)
> resp.  The former is OK unless you have restrictions on register pairs that
> can be used for 64bit; the latter is past the 5-register limit no matter what,
> so the wrapper is really needed.

Unless I'm misreading ocavr32.pdf, that should be (R12, R10:R11, R9, R8) and
(R12, R10:R11, R9:R8, stack) resp., so fadvise64 doesn't need a wrapper, but
fadvise64_64 does.  And something like (s32, s32, s64, s64) would turn into
(R12, R11, R9:R8, stack, stack); AFAICS, we don't have anything that ugly...

Automating *that* is going to be interesting...  I've not given up, but it's
not going to be fun ;-/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/