On 04/20/2011 06:18 PM, fykc...@gmail.com wrote:
2011/4/21 Eric Paris<epa...@redhat.com>:
I am pretty arch stupid, and I have no idea at all if it is related, but
I'm looking at kernel commit 5e844b31c2ace282ab8bea630b63e0212d9532d4
which wires up the fanotify syscalls for mips. I see that it used a u64
for a3 and a4 when these are only going to be 32 values. Does that
matter? I also see that some prototype such as sys32_readahead()
explicitly added a pad into the 32 helper. Should we be doing that?
This will break the direct system call way.
I also notice that the naming of arguments seems wrong (although it
shouldn't matter)
SYSCALL_DEFINE6(32_fanotify_mark, int, fanotify_fd, unsigned int, flags,
u64, a3, u64, a4, int, dfd, const char __user *, pathname)
IMHO, rearrange the order of arguments can do the trick(But API
changes). e.g. exchange positions of 'mark' and 'flags'. mark will in
a 64-aligned position in case of indirect syscall. In direct syscall,
libc can take care of it.
IMHO, the API is set in stone. So any talk of changing it is moot.
David Daney
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
