linux-kernel - Re: HTC Dream aka. t-mobile g1 support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 11 Jun 2009 13:18:23 +0200
From:	Pavel Machek <pavel@....cz>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	David Miller <davem@...emloft.net>, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.arm.linux.org.uk, ibm@...roid.com,
	swetland@...gle.com, san@...roid.com, rlove@...gle.com
Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu 2009-06-11 11:34:57, Russell King - ARM Linux wrote:
> On Thu, Jun 11, 2009 at 09:37:40AM +0200, Pavel Machek wrote:
> > On Thu 2009-06-11 00:02:19, David Miller wrote:
> > > From: Russell King - ARM Linux <linux@....linux.org.uk>
> > > Date: Wed, 10 Jun 2009 20:48:52 +0100
> > > 
> > > > In short not as far as I know, and I'm very disappointed with the state
> > > > of affairs with google.
> > > 
> > > And of course, this whole android situation has absolutely nothing to
> > > do with how much of a pain in that ass you are to deal with as ARM
> > > maintainer.
> > 
> > Well, linux-arm-devel being subscribers-only and patch management
> > system that needs special headers certainly does not help here :-(.
> 
> That's got nothing to do with it.  You're just using that as an excuse
> to bash me with.

I believe it has something to do with it. linux-arm is effectively a
walled garden, away from lkml. Getting patches to linux-arm is more
interesting exercise than getting them to linux-i386. For trivial
patches, it matters.

> However, as a result of the complete lack of effort to update patches
> as a result of feedback coupled with my lack of bandwidth to review
> complex code implementing things like cross-bridge APIs (eg, ARM <->
> DSP communications channels), Brian basically gave up trying to get
> stuff into mainline.

> Now, ask yourself this question: why should I have to be the one to
> review things like ARM <-> DSP communication channel code?  Hint: I
> don't want to because I know nothing about the subject.  Where should
> I send these people to get such code reviewed?  No idea, there seems
> to be no one _anywhere_ who would seem to be interested in it.

I guess the patches should just go to lkml. If 

1) they don't mess up common code

2) google is willing to maintain them

3) they look mostly okay to interested parties on lkml

... I guess they should just go in. Maybe they should go into
drivers/dsp or drivers/mfd or something if you are not comfortable
having them in arch/arm.

They can certianly go to drivers/staging...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/