Re: [patch 05/11] syslets: core code

[Linus Torvalds <torvalds@linux-foundation.org>]

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/