[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070427142254.3aa89a16.randy.dunlap@oracle.com>
Date: Fri, 27 Apr 2007 14:22:54 -0700
From: Randy Dunlap <randy.dunlap@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Artem Bityutskiy <dedekind@...radead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Josh Boyer <jwboyer@...ux.vnet.ibm.com>,
David Woodhouse <dwmw2@...radead.org>,
Frank Haverkamp <haver@...t.ibm.com>
Subject: Re: [GIT-PULL] please pull UBI tree
On Fri, 27 Apr 2007 13:52:24 -0700 Andrew Morton wrote:
> On Fri, 27 Apr 2007 09:00:25 -0700 (PDT)
> Linus Torvalds <torvalds@...ux-foundation.org> 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.
I have a version of that from James Ketrenos that I have been working
on... Can post in a few days.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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