On Thu, 15 Feb 2007, Evgeniy Polyakov wrote:
> >
> > 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.
>
> Well, if we can setup iocb structure, why we can not setup syslet one?
(I'm cutting wildly, to try to get to the part I wanted to answer)
I actually think aio_read/write() and friends are *horrible* interfaces.
Here's a quick question: how many people have actually ever seen them used
in "normal code"?
Yeah. Nobody uses them. They're not all that portable (even within unixes
they aren't always there, much less in other places), they are fairly
obscure, and they are just not really easy to use.
Guess what? The same is going to be true *in*spades* for any Linux-
specific async system call thing.
This is why I think simplicity of use along with transparency, is so
important. I think "aio_read()" is already a nasty enough interface, and
it's sure more portable than any Linux-specific extension will be (only
until the revolution comes, of course - at that point, everybody who
doesn't use Linux will be up against the wall, so we can solve the problem
that way).
So a Linux-specific extension needs to be *easier* to use or at least
understand, and have *more* obvious upsides than "aio_read()" has.
Otherwise, it's pointless - nobody is really going to use it.
This is why I think the main goals should be:
- the *internal* kernel goal of trying to replace some very specific
aio_read() etc code with somethign more maintainable.
This is really a maintainability argument, nothing more. Even if we
never do anything *but* aio_read() and friends, if we can avoid having
the VFS code have multiple code-paths and explicit checks for AIO, and
instead handle it more "automatically", I think it is already worth it.
- add extensions that people *actually*can*use* in practice.
And this is where "simple interfaces" comes in.
> So there is no point in 'complex setup and overhead', but there is
> a. limit of the AIO (although my point is not to have huge amount of
> working threads - they were created by people who can not
> program state machines (c) Alan Cox)
> b. possibility to implement a state machine (in current form likely will
> not be used except maybe some optional hints for IO tasks like
> fadvice)
> c. in all other ways it has all pros and cons of micro-thread design (it
> looks neat and simple, although is utterly broken in some usage
> cases).
I don't think the "atom" approach is bad per se. I think it could be fine
to have some state information in user space. It's just that I think
complex interfaces that people largely won't even use is a big mistake. We
should concentrate on usability first, and some excessive cleverness
really isn't a big advantage.
Being able to do a "open + stat" looks like a fine thing. But I doubt
you'll see a lot of other combinations.
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]
