Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261416AbVANXDT (ORCPT ); Fri, 14 Jan 2005 18:03:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261993AbVANXCo (ORCPT ); Fri, 14 Jan 2005 18:02:44 -0500 Received: from mail8.fw-bc.sony.com ([160.33.98.75]:56979 "EHLO mail8.fw-bc.sony.com") by vger.kernel.org with ESMTP id S261917AbVANXA2 (ORCPT ); Fri, 14 Jan 2005 18:00:28 -0500 Message-ID: <41E84E9E.1000907@am.sony.com> Date: Fri, 14 Jan 2005 14:58:38 -0800 From: Tim Bird User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: karim@opersys.com CC: Roman Zippel , Andi Kleen , Nikita Danilov , linux-kernel@vger.kernel.org, Tom Zanussi , ltt-dev Subject: Re: 2.6.11-rc1-mm1 References: <20050114002352.5a038710.akpm@osdl.org> <20050114103836.GA71397@muc.de> <41E7A7A6.3060502@opersys.com> <41E8358A.4030908@opersys.com> In-Reply-To: <41E8358A.4030908@opersys.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2073 Lines: 50 Karim Yaghmour wrote: > Roman Zippel wrote: >>You don't think that's a little overkill? > >Based on the descriptions below, I think Roman is right. There's too much going on here for the average user. I haven't looked closely, but some of the stuff seems to be for esoteric use cases. There are two ways to approach it: - add a simplified API for the most common usage - strip out the stuff that's not really needed, and figure out workarounds for things (like tracing initialization) that need special assistance. Some of these options (e.g. bufsize) are available to the user via tracedaemon. I can honestly say I haven't got a clue what to use for some of them, and so always leave them at defaults. > I can see why you'd say this as a first impression, but really it isn't. > > Here's a simple primer to this call's parameters: > channel_path, mode: > Where does this appear in relayfs and what rights do > user-space apps have over it (rwx). > bufsize, nbufs: > Usually things have to be subdivided in sub-buffers to make > both writing and reading simple. LTT uses this to allow, > among other things, random trace access. Could these be simplified to a few enumerated modes? > channel_flags, channel_callbacks: > start_reserve, end_reserve, rchan_start_reserve: > resize_min, resize_max: > init_buf, init_buf_size: It seems like you could remove these from relay_open() and move them to get()/set() operations if you wanted to simplify the open API. Or, you could create other (separate) APIs to pre-fill the buffer or reserve space. Do you want me to take a look at this and propose some specific changes? (I won't get to this until Monday, though). ============================= Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Electronics ============================= - 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/