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

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

On Thu, Feb 15, 2007 at 09:42:32AM -0800, Linus Torvalds (torvalds@linux-foundation.org) 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 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/