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]

Date:	Thu, 11 Jun 2009 21:51:53 -0400 (EDT)
From:	Nicolas Pitre <nico@....org>
To:	Ryan Mallon <ryan@...ewatersys.com>
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, lkml <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

On Fri, 12 Jun 2009, Ryan Mallon wrote:

> Nicolas Pitre wrote:
> > 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?

I think that, at some point, if nobody else has the interest/hardware, 
then you are on your own.  Just make sure that your code respects the 
kernel coding style, has no obvious API misuses, and that it does not 
affect anyone else.  At that point if you can convince people that your 
code is actually useful and that you'll be around to quickly respond 
if/when issues are reported then it should just be merged.


Nicolas
--
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/