kre writes: 

| except that there are a lot of syscalls all of which would need to be
| modified to have this extra flag.   Many (most) of them have no easy way
| to be extended to pass a flag though (not having a convenient flags arg
| like open(2)).   I suppose you could redefine link(2) so that if the
| first byte in the first filename was 0xff then that was a flag, and
| not part of the pathname, or something, but I doubt any of us would like
| to see that...

Is it really disgusting to suggest that one generalizes this type of flag
to *all* syscalls?  There are several ways of indicating, "this syscall
uses a different uid" or the like, putting either the library or the
compiler to work for one in selecting the correct atomic syscall.

Perhaps, instead of your magic_next_syscall(); open(...); and doing 
bookkeeping to make it behave atomically, we actually make it atomic
and end up coding either magic_open(magic_data, open_arg_0, open_arg_1, ...)
or magic_syscall(magic_data, open, open_arg_0, ...), either of which
traps immediately to the kernel.

I kinda like the curried version, since one can decide the
syscall can't do whatever magic is required, and handle the
error condition, without changing any of the syscall's code.

	Sean.