Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030367AbXBORtL (ORCPT ); Thu, 15 Feb 2007 12:49:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030371AbXBORtK (ORCPT ); Thu, 15 Feb 2007 12:49:10 -0500 Received: from smtp.osdl.org ([65.172.181.24]:54492 "EHLO smtp.osdl.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030367AbXBORtI (ORCPT ); Thu, 15 Feb 2007 12:49:08 -0500 Date: Thu, 15 Feb 2007 09:42:32 -0800 (PST) From: Linus Torvalds To: Evgeniy Polyakov cc: Ingo Molnar , Linux Kernel Mailing List , Arjan van de Ven , Christoph Hellwig , Andrew Morton , Alan Cox , Ulrich Drepper , Zach Brown , "David S. Miller" , Benjamin LaHaise , Suparna Bhattacharya , Davide Libenzi , Thomas Gleixner Subject: Re: [patch 05/11] syslets: core code In-Reply-To: <20070215163704.GA32609@2ka.mipt.ru> Message-ID: References: <20070213142035.GF638@elte.hu> <20070215133550.GA29274@2ka.mipt.ru> <20070215163704.GA32609@2ka.mipt.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2497 Lines: 58 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/