On Thu, 15 Feb 2007, Evgeniy Polyakov wrote:
>
> Userspace_API_is_the_ever_possible_last_thing_to_ever_think_about. Period
> . // <- wrapped one
No, I really think you're wrong.
In many ways, the interfaces and especially data structures are *more*
important than the code.
The code we can fix. The interfaces, on the other hand, we'll have to live
with forever.
So complex interfaces that expose lots of implementation detail are not a
good thing, and it's _not_ the last thing you want to think about. Complex
interfaces with a lot of semantic knowledge seriously limit how you can
fix things up later.
In contrast, simple interfaces that have clear and unambiguous semantics
and that can be explained at a conceptual level are things that you can
often implement in many different ways. So the interface isn't the bottle
neck: you may have to have a "backwards compatibility layer" for it
> If system is designed that with API changes it breaks - that system sucks
> wildly and should be thrown away. Syslets do not suffer from that.
The syslet code itself looks fine. It's the user-visible part I'm not
convinced about.
I'm just saying: how would use use this for existing programs?
For something this machine-specific, you're not going to have any big
project written around the "async atom" code. So realistically, the kinds
of usage we'd see is likely some compile-time configuration option, where
people replace some specific sequence of code with another one. THAT is
what we should aim to make easy and flexible, I think. And that is where
interfaces really are as important as code.
We know one interface: the current aio_read() one. Nobody really _likes_
it (even database people would apparently like to extend it), but it has
the huge advantage of "being there", and having real programs that really
care that use it today.
Others? We don't know yet. And exposing complex interfaces that may not be
the right ones is much *worse* than exposing simple interfaces (that
_also_ may not be the right ones, of course - but simple and
straightforward interfaces with obvious and not-very-complex semantics are
a lot easier to write compatibility layers for if the internal code
changes radically)
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]
