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 for Android: free password hash cracker in your pocket

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

Message-ID: <4A31AECA.6070303@bluewatersys.com>
Date:	Fri, 12 Jun 2009 13:26:34 +1200
From:	Ryan Mallon <ryan@...ewatersys.com>
To:	Nicolas Pitre <nico@....org>
CC:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Tony Lindgren <tony@...mide.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	David Miller <davem@...emloft.net>, swetland@...gle.com,
	pavel@....cz, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.arm.linux.org.uk, san@...roid.com,
	rlove@...gle.com
Subject: Re: HTC Dream aka. t-mobile g1 support

Nicolas Pitre wrote:
> On Fri, 12 Jun 2009, Ryan Mallon wrote:
> 
>> Nicolas Pitre wrote:
>>> On Thu, 11 Jun 2009, Russell King - ARM Linux wrote:
>>>
>>> I think that you, as the ARM maintainer, should continue gathering all 
>>> the ARM subarchitectures into a coherent ARM tree and arbitrate 
>>> conflicts when they occur.  You should especially keep a tight control 
>>> on the very core ARM code.  But everything under arch/arm/mach-* you 
>>> should let people maintaining those have control of that themselves and 
>>> free yourself from that responsibility as much as possible.  The current 
>>> directory structure is quite indicative of where the boundaries are 
>>> already.  This way, if I make a mess of arch/arm/mach-orion5x/* then you 
>>> just need to pass the blame straight to me.
>>>
>> That works okay for the more popular sub-architectures like pxa, etc,
>> where there are a lot of people to review code and sort out issues
>> between themselves. However, for the architecture I do most of my work
>> on, ep93xx, there are basically two of us, Hartley and myself, doing
>> active work.
>>
>> It seems a bit dodgy if all the patches to ep93xx are written by one of
>> us and acked by the other with no input from anybody else. It would be
>> very easy for the ep93xx code to become and complete mess, and lack any
>> coherency with the other sub-archs. I prefer having Russell, or somebody
>> else, at least have a glance at the patches before they get applied.
> 
> This is all fine.  If you prefer some external help to judge your 
> patches that's OK.  In fact I'm not advocating for people to stop 
> posting their patches to linux-arm-kernel at all.  It is a good thing 
> for patches to be aired on the mailing list for everyone to see and 
> comment.
> 
> However if you start gathering more developers around the ep93xx then 
> someone should take charge and be responsible for it.  And this must not 
> necessarily be Russell as his cycles are not infinite.

Thats my point though: In the meantime, it falls on Russell by default
to be the one to verify all the patches going through. I think the same
is true for new architectures, if nobody else has the interest/hardware
besides those posting the patches, then who is meant to do the
reviewing/acking?

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

       Ryan Mallon                              Unit 5, Amuri Park
       Phone: +64 3 3779127                     404 Barbadoes St
       Fax:   +64 3 3779135                     PO Box 13 889
       Email: ryan@...ewatersys.com             Christchurch, 8013
       Web:   http://www.bluewatersys.com       New Zealand
       Freecall Australia  1800 148 751         USA 1800 261 2934
--
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/