Date:	Thu, 15 Feb 2007 11:28:57 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Evgeniy Polyakov <johnpol@....mipt.ru>
cc:	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@....com.au>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Ulrich Drepper <drepper@...hat.com>,
	Zach Brown <zach.brown@...cle.com>,
	"David S. Miller" <davem@...emloft.net>,
	Benjamin LaHaise <bcrl@...ck.org>,
	Suparna Bhattacharya <suparna@...ibm.com>,
	Davide Libenzi <davidel@...ilserver.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [patch 05/11] syslets: core code



On Thu, 15 Feb 2007, Evgeniy Polyakov wrote:
> > 
> > See? The example you tried to use to show how "simple" the interface iswas 
> > actually EXACTLY THE REVERSE. It shows how subtle bugs can creep in!
> 
> So describe what are the requirements (constraints)?
> 
> Above example has exactly one syscall in the chain, so it is ok, but
> generally it is not correct.

Well, it *could* be correct. It depends on the semantics of the atom 
fetching. If we make the semantics be that the first atom is fetched 
entirely synchronously, then we could make the rule be that single-syscall 
async things can do their job with a temporary allocation.

So that wasn't my point. My point was that a complicated interface that 
uses indirection actually has subtle issues. You *thought* you were doing 
something simple, and you didn't even realize the subtle assumptions you 
made.

THAT was the point. Interfaces are really really subtle and important. 
It's absolutely not a case of "we can just write wrappers to fix up any 
library issues".

> So instead there will be 
> s = atom_create_and_add(__NR_stat, path, stat, NULL, NULL, NULL, NULL);
> atom then can be freed in the glibc_async_wait() wrapper just before
> returning data to userspace.

So now you add some kind of allocation/dealloction thing. In user space or 
in the kernel?

> There are millions of possible ways to do that, but what exactly one
> should be used from your point of view? Describe _your_ vision of that path.

My vision is that we should be able to do the simple things *easily* and 
without any extra overhead.

And doing wrappers in user space is almost entirely unacceptable, becasue 
a lot of the wrapping needs to be done at release time (for example: 
de-allocating memory), and that means that you no longer can do simple 
system calls that don't even need release notification AT ALL.

> Currently generic example is following:
> allocate mem
> setup complex structure
> submit syscall
> wait syscall
> free mem

And that "allocate mem" and "free mem" is a problem. It's not just a 
performance problem, it is a _complexity_ problem. It means that people 
have to track things that they are NOT AT ALL INTERESTED IN!

> So, describe how exactly _you_ think it should be implemented with its
> pros and cons, so that systemn could be adopted without trying to
> mind-read of what is simple and good or complex and really bad.

So I think that a good implementation just does everything up-front, and 
doesn't _need_ a user buffer that is live over longer periods, except for 
the actual results. Exactly because the whole alloc/teardown is nasty.

And I think a good implementation doesn't need wrapping in user space to 
be useful - at *least* not wrapping at completion time, which is the 
really difficult one (since, by definition, in an async world completion 
is separated from the initial submit() event, and with kernel-only threads 
you actually want to *avoid* having to do user code after the operation 
completed).

I suspect Ingo's thing can do that. But I also suspect (nay, _know_, from 
this discussion), that you didn't even think of the problems.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists