LWN: Comments on "System calls and 64-bit architectures"

System calls and 64-bit architectures

jlokier — 2008-12-21T22:51:45+00:00

Except that Linux AIO (io_submit) isn't always asynchronous, and you can't easily tell when it will block the caller.

Some folks asking for preadv/pwritev are actually doing so because they rejected Linux AIO for being too broken to use.

They are preferring to use preadv/pwritev in userspace helper threads, than Linux AIO, because at least with threads it is always asynchronous.

System calls and 64-bit architectures

rwmj — 2008-12-20T11:14:29+00:00

This is quite an interesting problem, and one we've also encountered with virtualization. Paravirtualized guests are a bit like processes, and like processes they can make hypercalls (which are a bit like system calls).

Where the complexity arises is system administrators want to run a mixture of 32 bit and 64 bit guests on a system (and on crazy architectures like IA64, they can even run a mixture of big and little endian guests). So there's a degree of complexity ensuring the guests are all passing identical C structs to hypercalls, particularly in the "32-on-64" case.

Rich.

System calls and 64-bit architectures

felixfix — 2008-12-19T23:08:57+00:00

That must be the security bit for packets of which I have heard mention now and then ... sort of like Perl's taint flag, maybe.

System calls and 64-bit architectures

vonbrand — 2008-12-18T17:02:18+00:00

The problem is the lefover 65th bit ;-)

System calls and 64-bit architectures

liljencrantz — 2008-12-18T14:56:48+00:00

This may be a silly question, but what is the problem with simply fixing glibc to send 65-bit data properly aligned?

System calls and 64-bit architectures

abatters — 2008-12-18T13:40:28+00:00

While you are at it, put a direction flag in each vector so that you can submit reads and writes at the same time. And put the file descriptor in each vector too so that you can submit I/O to different files with one syscall. Then make it asynchronous and add in an optional signal upon completion. Oh wait, io_submit() already does all that.

System calls and 64-bit architectures

ballombe — 2008-12-18T12:42:45+00:00

The article title seems a bit of a misnomer. The issue is with 64bit syscalls arguments on 32bit architectures (or emulation of 32bit architectures), rather than an issue with 64bit architectures.

System calls and 64-bit architectures

meuh — 2008-12-18T09:51:46+00:00

Why not extend struct iovec with an offset field:

struct iovecs
{
  void  *iovs_base;
  size_t iovs_len;
  off_t  iovs_off;
};

ssize_t preadv(int d, const struct iovecs *iovs, int iovcnt);
ssize_t pwritev(int d, const struct iovecs *iovs, int iovcnt);

Bad things could happen if offsets are going backward:performance penality or data overlapping. And this kind of interface are not the best regarding to error report. So the kernel would have to enforce (iovs[n].iovs_off + iovs[n].iovs_len) < iovs[n+1].iovs_off

System calls and 64-bit architectures

quotemstr — 2008-12-18T05:58:57+00:00

syscall calling convention is not the platform's stdcall.

System calls and 64-bit architectures

kbob — 2008-12-18T05:22:19+00:00

This doesn't seem like a kernel issue. If gcc can't call a function whose fourth argument is an int64_t, then either gcc or that platform's ABI is broken.