> |> A sufficient number take the unavailability of new syscall in everybody's
> |> glibc as a sufficient excuse for broken code. util-linux as a major
> |> offender comes to mind or also e2fsprogs.
> Userspace should be using syscall(2/3) for new syscalls.
Which just replaces one problem with another, slightly smaller one.
So something like syscall(SYS_pwrite, fd, buf, count, pos) will not work
on all architectures because pos is a 64-bit argument which as to be
passed in an aligned register pair on some machines, so an additional
argument has to be inserted. So the glorious attempt to use syscall()
will now write data to fantasy positions in a file. Great. And just
an example demonstrating that the syscall interface is seriously dangerous
and non-portable. I don't think there is anyway except people limiting
themselfes APIs provided by libc or similar but not using syscalls directly.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/