linux-kernel - Re: [PATCH 03/29] gma500: Ensure the frame buffer has a linear virtual mapping

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:	Tue, 28 Jun 2011 23:41:52 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 03/29] gma500: Ensure the frame buffer has a linear
 virtual mapping

> I am still wondering how come that this is causing trouble to anyone 
> though -- is anyone really developing real code on top of linux-next 
> (which should be there to cross-check merge problems between subsystems 
> and test functionality) instead of particular subsystem tree?

I run -next on a regular basis. I'm actually doing a lot of Linux mid
development on it because I need bits going via various trees from x86 to
staging to input together.

I'm not btw saying your approach is wrong - in fact I imagine its the
only way to make it managable for some things but in the gma500 case at
least and I suspect much of staging it tends to cause merge problems. It
would be helpful if you route any gma500 bits via me because of the
amount of change in that subtree.

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