Around Mon 04 Feb 2013 08:34:47 -0800 or thereabout, Håvard Skinnemoen wrote:
> On Mon, Feb 4, 2013 at 7:39 AM, Al Viro wrote:
>> On Sun, Feb 03, 2013 at 09:35:39PM -0800, H?vard Skinnemoen wrote:
>>>
>>> > But yes, 32bit/32bit/64bit/32bit is another interesting case -
>>> > fanotify_mark is
Around Mon 04 Feb 2013 08:34:47 -0800 or thereabout, Håvard Skinnemoen wrote:
On Mon, Feb 4, 2013 at 7:39 AM, Al Viro v...@zeniv.linux.org.uk wrote:
On Sun, Feb 03, 2013 at 09:35:39PM -0800, H?vard Skinnemoen wrote:
But yes, 32bit/32bit/64bit/32bit is another interesting case -
On Mon, Feb 04, 2013 at 08:34:47AM -0800, H?vard Skinnemoen wrote:
> > So it will use the gap in case of 32/32/64/32; the first two calls will
> > take index 0 and 64bit (r12 and r11 resp.), the third will take 3 and 4
> > (r9:r8) and the fourth will take 2 (r10).
>
> Oh, cool. I guess I am
On Mon, Feb 4, 2013 at 7:39 AM, Al Viro wrote:
> On Sun, Feb 03, 2013 at 09:35:39PM -0800, H?vard Skinnemoen wrote:
>>
>> > But yes, 32bit/32bit/64bit/32bit is another interesting case -
>> > fanotify_mark is 32/32/64/32/32. From what ABI says it would seem to
>> > be r12/r11/r8:r9/r10/stack,
On Sun, Feb 03, 2013 at 09:35:39PM -0800, H?vard Skinnemoen wrote:
> Right.
>
> > But yes, 32bit/32bit/64bit/32bit is another interesting case -
> > fanotify_mark is 32/32/64/32/32. From what ABI says it would seem to
> > be r12/r11/r8:r9/r10/stack, but if I understand you correctly, we'll
> >
On Sun, Feb 03, 2013 at 09:35:39PM -0800, H?vard Skinnemoen wrote:
Right.
But yes, 32bit/32bit/64bit/32bit is another interesting case -
fanotify_mark is 32/32/64/32/32. From what ABI says it would seem to
be r12/r11/r8:r9/r10/stack, but if I understand you correctly, we'll
end up
On Mon, Feb 4, 2013 at 7:39 AM, Al Viro v...@zeniv.linux.org.uk wrote:
On Sun, Feb 03, 2013 at 09:35:39PM -0800, H?vard Skinnemoen wrote:
But yes, 32bit/32bit/64bit/32bit is another interesting case -
fanotify_mark is 32/32/64/32/32. From what ABI says it would seem to
be
On Mon, Feb 04, 2013 at 08:34:47AM -0800, H?vard Skinnemoen wrote:
So it will use the gap in case of 32/32/64/32; the first two calls will
take index 0 and 64bit (r12 and r11 resp.), the third will take 3 and 4
(r9:r8) and the fourth will take 2 (r10).
Oh, cool. I guess I am wrong then.
On Sun, Feb 3, 2013 at 9:05 PM, Al Viro wrote:
> On Sun, Feb 03, 2013 at 08:52:18PM -0800, H?vard Skinnemoen wrote:
>
>> You're right on -- in this case, the compiler will skip r10, and do
>> (r12, r11, r8:r9, stack). We pass the syscall number in r8, but we
>> also unconditionally move r7 to r8
On Sun, Feb 03, 2013 at 08:52:18PM -0800, H?vard Skinnemoen wrote:
> You're right on -- in this case, the compiler will skip r10, and do
> (r12, r11, r8:r9, stack). We pass the syscall number in r8, but we
> also unconditionally move r7 to r8 in the syscall path, so it
> shouldn't matter (libc
On Sun, Feb 3, 2013 at 7:02 PM, Al Viro wrote:
> On Mon, Feb 04, 2013 at 01:31:11AM +, Al Viro wrote:
>
>> 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
On 02/03/2013 05:31 PM, Al Viro wrote:
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,
On Mon, Feb 04, 2013 at 01:31:11AM +, Al Viro wrote:
> 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
>
On Mon, Feb 04, 2013 at 12:30:47AM +, Al Viro wrote:
> On Mon, Feb 04, 2013 at 12:10:55AM +, 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
> > > >
On Mon, Feb 04, 2013 at 12:10:55AM +, 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
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
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
On Mon, Feb 04, 2013 at 12:10:55AM +, 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
On Mon, Feb 04, 2013 at 12:30:47AM +, Al Viro wrote:
On Mon, Feb 04, 2013 at 12:10:55AM +, 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
On Mon, Feb 04, 2013 at 01:31:11AM +, Al Viro wrote:
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,
On 02/03/2013 05:31 PM, Al Viro wrote:
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,
On Sun, Feb 3, 2013 at 7:02 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Mon, Feb 04, 2013 at 01:31:11AM +, Al Viro wrote:
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
On Sun, Feb 03, 2013 at 08:52:18PM -0800, H?vard Skinnemoen wrote:
You're right on -- in this case, the compiler will skip r10, and do
(r12, r11, r8:r9, stack). We pass the syscall number in r8, but we
also unconditionally move r7 to r8 in the syscall path, so it
shouldn't matter (libc does
On Sun, Feb 3, 2013 at 9:05 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Sun, Feb 03, 2013 at 08:52:18PM -0800, H?vard Skinnemoen wrote:
You're right on -- in this case, the compiler will skip r10, and do
(r12, r11, r8:r9, stack). We pass the syscall number in r8, but we
also unconditionally
On Sun, Jan 27, 2013 at 7:50 PM, Matthias Brugger
wrote:
> This patch adds dummy syscalls so that compiling
> for this architecture does not provoke warnings when
> checksyscalls.sh is called.
Nice, but...
> --- a/arch/avr32/kernel/syscall_table.S
> +++ b/arch/avr32/kernel/syscall_table.S
> @@
Around Sun 27 Jan 2013 20:30:09 + or thereabout, Al Viro wrote:
> On Sun, Jan 27, 2013 at 08:57:14PM +0100, Hans-Christian Egtvedt wrote:
>> Around Sun 27 Jan 2013 13:50:15 +0100 or thereabout, Matthias Brugger wrote:
>> > This patch adds dummy syscalls so that compiling
>> > for this
On Sun, Jan 27, 2013 at 08:57:14PM +0100, Hans-Christian Egtvedt wrote:
> Around Sun 27 Jan 2013 13:50:15 +0100 or thereabout, Matthias Brugger wrote:
> > This patch adds dummy syscalls so that compiling
> > for this architecture does not provoke warnings when
> > checksyscalls.sh is called.
>
>
Around Sun 27 Jan 2013 13:50:15 +0100 or thereabout, Matthias Brugger wrote:
> This patch adds dummy syscalls so that compiling
> for this architecture does not provoke warnings when
> checksyscalls.sh is called.
Does any of these syscalls take more than 5 arguments? If so, it is also
needed to
This patch adds dummy syscalls so that compiling
for this architecture does not provoke warnings when
checksyscalls.sh is called.
Signed-off-by: Matthias Brugger
---
arch/avr32/include/asm/unistd.h | 2 +-
arch/avr32/include/uapi/asm/unistd.h | 29 +
This patch adds dummy syscalls so that compiling
for this architecture does not provoke warnings when
checksyscalls.sh is called.
Signed-off-by: Matthias Brugger matthias@gmail.com
---
arch/avr32/include/asm/unistd.h | 2 +-
arch/avr32/include/uapi/asm/unistd.h | 29
Around Sun 27 Jan 2013 13:50:15 +0100 or thereabout, Matthias Brugger wrote:
This patch adds dummy syscalls so that compiling
for this architecture does not provoke warnings when
checksyscalls.sh is called.
Does any of these syscalls take more than 5 arguments? If so, it is also
needed to do
On Sun, Jan 27, 2013 at 08:57:14PM +0100, Hans-Christian Egtvedt wrote:
Around Sun 27 Jan 2013 13:50:15 +0100 or thereabout, Matthias Brugger wrote:
This patch adds dummy syscalls so that compiling
for this architecture does not provoke warnings when
checksyscalls.sh is called.
Does any
Around Sun 27 Jan 2013 20:30:09 + or thereabout, Al Viro wrote:
On Sun, Jan 27, 2013 at 08:57:14PM +0100, Hans-Christian Egtvedt wrote:
Around Sun 27 Jan 2013 13:50:15 +0100 or thereabout, Matthias Brugger wrote:
This patch adds dummy syscalls so that compiling
for this architecture does
On Sun, Jan 27, 2013 at 7:50 PM, Matthias Brugger
matthias@gmail.com wrote:
This patch adds dummy syscalls so that compiling
for this architecture does not provoke warnings when
checksyscalls.sh is called.
Nice, but...
--- a/arch/avr32/kernel/syscall_table.S
+++
34 matches
Mail list logo
