On Tue, 13 Feb 2007, Ingo Molnar wrote:
>
> the core syslet / async system calls infrastructure code.
Ok, having now looked at it more, I can say:
- I hate it.
I dislike it intensely, because it's so _close_ to being usable. But the
programming interface looks absolutely horrid for any "casual" use, and
while the loops etc look like fun, I think they are likely to be less than
useful in practice. Yeah, you can do the "setup and teardown" just once,
but it ends up being "once per user", and it ends up being a lot of stuff
to do for somebody who wants to just do some simple async stuff.
And the whole "lock things down in memory" approach is bad. It's doing
expensive things like mlock(), making the overhead for _single_ system
calls much more expensive. Since I don't actually believe that the
non-single case is even all that interesting, I really don't like it.
I think it's clever and potentially useful to allow user mode to see the
data structures (and even allow user mode to *modify* them) while the
async thing is running, but it really seems to be a case of excessive
cleverness.
For example, how would you use this to emulate the *current* aio_read()
etc interfaces that don't have any user-level component except for the
actual call? And if you can't do that, the whole exercise is pointless.
Or how would you do the trivial example loop that I explained was a good
idea:
struct one_entry *prev = NULL;
struct dirent *de;
while ((de = readdir(dir)) != NULL) {
struct one_entry *entry = malloc(..);
/* Add it to the list, fill in the name */
entry->next = prev;
prev = entry;
strcpy(entry->name, de->d_name);
/* Do the stat lookup async */
async_stat(de->d_name, &entry->stat_buf);
}
wait_for_async();
.. Ta-daa! All done ..
Notice? This also "chains system calls together", but it does it using a
*much* more powerful entity called "user space". That's what user space
is. And yeah, it's a pretty complex sequencer, but happily we have
hardware support for accelerating it to the point that the kernel never
even needs to care.
The above is a *realistic* schenario, where you actually have things like
memory allocation etc going on. In contrast, just chaining system calls
together isn't a realistic schenario at all.
So I think we have one _known_ usage schenario:
- replacing the _existing_ aio_read() etc system calls (with not just
existing semantics, but actually binary-compatible)
- simple code use where people are willing to perhaps do something
Linux-specific, but because it's so _simple_, they'll do it.
In neither case does the "chaining atoms together" seem to really solve
the problem. It's clever, but it's not what people would actually do.
And yes, you can hide things like that behind an abstraction library, but
once you start doing that, I've got three questions for you:
- what's the point?
- we're adding overhead, so how are we getting it back
- how do we handle independent libraries each doing their own thing and
version skew between them?
In other words, the "let user space sort out the complexity" is not a good
answer. It just means that the interface is badly designed.
Linus
-
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]
