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. -- Regards, - cee1 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel