linux-kernel - Re: thoughts on requiring multi-arch support for arm drm drivers?

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] [day] [month] [year] [list]

Date:	Mon, 21 Jan 2013 08:28:05 +0100
From:	Thierry Reding <thierry.reding@...onic-design.de>
To:	Daniel Vetter <daniel.vetter@...ll.ch>
Cc:	Rob Clark <robdclark@...il.com>, dri-devel@...ts.freedesktop.org,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Lucas Stach <dev@...xeye.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>
Subject: Re: thoughts on requiring multi-arch support for arm drm drivers?

On Sun, Jan 20, 2013 at 04:42:55PM +0100, Daniel Vetter wrote:
> On Sun, Jan 20, 2013 at 4:08 PM, Rob Clark <robdclark@...il.com> wrote:
> > One thing I've run into in the past when trying to make changes in drm
> > core, and Daniel Vetter has mentioned the same, is that it is a bit of
> > a pain to compile test things for the arm drivers that do not support
> > CONFIG_ARCH_MULTIPLATFORM.  I went through a while back and fixed up
> > the low hanging fruit (basically the drivers that just needed a
> > Kconfig change).  But, IIRC some of the backlight related code in
> > shmob had some non-trivial plat dependencies.  And I think when tegra
> > came in, it introduced some non-trivial plat dependencies.
> >
> > What do others think about requiring multiarch or no arch dependencies
> > for new drivers, and cleaning up existing drivers.  Even if it is at
> > reduced functionality (like maybe #ifdef CONFIG_ARCH_SHMOBILE for some
> > of the backlight code in shmob) or doesn't even work but is just for
> > the purpose of being able to compile test the rest of the code?
> >
> > Thoughts?
> 
> Definitely in favour of this. Also, I think the arm world _really_
> needs something like Wu Fenggungs 0-day kernel testing/building
> machines, which checks every commit pushed to around a 150 git kernel
> maintainer repos with randconfigs, sparse (and iirc other static
> checkers like cocinelle), and test-boots them on kvm. It's not just
> that every driver seems to need it's own special defconfig/platform to
> even be selectable in Kconfig, they also seem to randomly (and often)
> break compilation if you're on the wrong tree or don't have the
> exactly required golden config ...

That's true. Unfortunately due to the many repositories involved there
seem to be quite a few dependencies involved to get all the pieces to
build properly. linux-next is usually in pretty good shape, however.
I've been running an automated build over at least all ARM defconfigs in
linux-next for a few days and sent out patches for build failures. But
I'm not sure if I can keep that up, or at least not on a daily basis.

Obviously it doesn't help the DRM problem all that much. But I agree
with Rob that the only thing that will really help is multi-platform
support.

Thierry

Content of type "application/pgp-signature" skipped