[lkml]   [2007]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2 of 4] Introduce i386 fibril scheduling
On Mon, 5 Feb 2007, Linus Torvalds wrote:

> Indeed. One word is *exactly* what a normal system call returns too.
> That said, normally we have a user-space library layer to turn that into
> the "errno + return value" thing, and in the case of async() calls we
> very basically wouldn't have that. So either:
> - 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.

Currently it's in the syscall wrapper. Couldn't we have it in the
asys_teardown_stack() stub?

> HOWEVER, they get returned differently. The cookie gets returned
> immediately, the system call result gets returned in-memory only after the
> async thing has actually completed.
> 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.

Yes. Let's have the userspace to "mark" the async operation. IMO the
cookie should be something transparent to the kernel.
Like you said though, that'd require compat-code (unless we fix the size).

- Davide

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-02-05 22:11    [W:0.133 / U:5.380 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site