linux-kernel - Re: [patch 05/11] syslets: core code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070215181059.GC20997@2ka.mipt.ru>
Date:	Thu, 15 Feb 2007 21:11:00 +0300
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
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, Feb 15, 2007 at 09:42:32AM -0800, Linus Torvalds (torvalds@...ux-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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/