- we'd need to do it in the kernel (which is actually nasty, since
different system calls have slightly different semantics - some
don't
return any error value at all, and negative numbers are real
numbers)
- we'd have to teach user space about the "negative errno"
mechanism, in
which case one word really is alwats enough.
Quite frankly, I much prefer the second alternative. The "negative
errno"
thing has not only worked really really well inside the kernel,
it's so
obviously 100% superior to the standard UNIX "-1 + errno" approach
that
it's not even funny.
I agree, and I imagine you'd have a hard time finding someone who
actually *likes* the errno convention :)
I would actually argue that it's not the kernel that should
generate any
cookie, but that user-space should *pass*in* the cookie it wants
to, and
the kernel should consider it a pointer to a 64-bit entity which is
the
return code.
Yup. That's how the current code (and epoll, and fs/aio.c, and..) work.
Cancelation comes into this discussion, I think. Hopefully its
reasonable to expect userspace to be able to manage cookies well
enough that they can use them to issue cancels and only hit the ops
they intend to. It means we have to give them the tools to
differentiate between a racing completion and cancelation so they can
reuse a cookie at the right time, but that doesn't sound fatal.
- make everything use 64-bit values.
This would be my preference.
Now, making an architecture-independent system call enumeration may
actually make sense regardless, because it would allow sys_async()
to have
its own system call table and put the limitations and rules for those
system calls there, instead of depending on the per-architecture
system
call table that tends to have some really architecture-specific
details.
Maybe, sure. I don't have a lot of insight into this. Hopefully
some arch maintainers can jump in?
- z
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
