Re: [GIT-PULL] please pull UBI tree

[Randy Dunlap <randy.dunlap@oracle.com>]

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@linux-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 ***