On Thu, Feb 15, 2007 at 09:42:32AM -0800, Linus Torvalds ([EMAIL PROTECTED])
wrote:
>
>
> 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
That's exaclt the way we should discuss it - you do ont like that
interface, but Ingo proposed a way to change that via table of async
syscalls - people asks, people answers - so eventually interface and (if
any) other problems got resolved.
> > 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)
So we just need to describe the way we want to see new interface -
that's it.
Here is a stub for async_stat() - probably broken example, but that does
not matter - this interface is really easy to change.
static void syslet_setup(struct syslet *s, int nr, void *arg1...)
{
s->flags = ...
s->arg[1] = arg1;
....
}
long glibc_async_stat(const char *path, struct stat *buf)
{
/* What about making syslet and/or set of atoms per thread and
preallocate
* them when working threads are allocated? */
struct syslet s;
syslet_setup(&s, __NR_stat, path, buf, NULL, NULL, NULL, NULL);
return async_submit(&s);
}
> Linus
--
Evgeniy Polyakov
-
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/
