From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755975AbXD0UxI (ORCPT ); Fri, 27 Apr 2007 16:53:08 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757004AbXD0UxI (ORCPT ); Fri, 27 Apr 2007 16:53:08 -0400 Received: from smtp1.linux-foundation.org ([65.172.181.25]:36537 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755975AbXD0UxE (ORCPT ); Fri, 27 Apr 2007 16:53:04 -0400 Date: Fri, 27 Apr 2007 13:52:24 -0700 From: Andrew Morton To: Linus Torvalds Cc: Artem Bityutskiy , Linux Kernel Mailing List , Josh Boyer , David Woodhouse , Frank Haverkamp Subject: Re: [GIT-PULL] please pull UBI tree Message-Id: <20070427135224.58d54065.akpm@linux-foundation.org> In-Reply-To: References: <1177677925.7539.18.camel@sauron> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 27 Apr 2007 09:00:25 -0700 (PDT) Linus Torvalds wrote: > On Fri, 27 Apr 2007, Artem Bityutskiy wrote: > > > > Linus, please, pull UBI tree from > > git://git.infradead.org/ubi-2.6.git for-linus > > > > The UBI tree has been in -mm for several releases and we would like to > > see it in the mainline. > > Quite frankly, I have absolutely _zero_ visibility into things like this, > so before I merge it I want ack's from various layers (preferably a > mixture of interests - are any vendors interested, is DavidW ok with this, > who is using it now and are the interfaces and designs correct etc etc?) > > So I simply cannot make that decision. I don't have the expertise or the > knowledge. I'll have to trust somebody else for things like this, and it > should be somebody who isn't "personally involved". > > In other words, I kind of want a sign-off from other parties, because I > can't pull things like this "blind". > > Are there (embedded?) vendors that already integrate this into their > kernel, or wait for it? Is dwmw supportive of this? Questions, questions.. The patchset used to contain lots of debugging support which wildly duplicated thigs which we already did and was generally overdone. That appears to all have been cleaned up now, so thanks for doing that. The one remaining nit I'd have with the debug code is that it adds a private hexdump() facility. By my count, that is the kernel's eighth hexdump implementation. There may be even more which don't have "hexdump" in their name. lib/hexdump.c is rather overdue.