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:   Wed, 15 Mar 2017 11:08:06 +0100
From:   Daniel Vetter <daniel@...ll.ch>
To:     Laura Abbott <labbott@...hat.com>
Cc:     Sumit Semwal <sumit.semwal@...aro.org>,
        linaro-mm-sig@...ts.linaro.org, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, linux-media@...r.kernel.org
Subject: Re: [RFC][PATCH] dma-buf: Introduce dma-buf test module

On Tue, Mar 14, 2017 at 01:30:30PM -0700, Laura Abbott wrote:
> On 03/14/2017 01:13 PM, Daniel Vetter wrote:
> > On Tue, Mar 14, 2017 at 01:04:19PM -0700, Laura Abbott wrote:
> >>
> >> dma-buf is designed to share buffers. Sharing means that there needs to
> >> be another subsystem to accept those buffers. Introduce a simple test
> >> module to act as a dummy system to accept dma_bufs from elsewhere. The
> >> goal is to provide a very simple interface to validate exported buffers
> >> do something reasonable. This is based on ion_test.c that existed for
> >> the Ion framework.
> >>
> >> Signed-off-by: Laura Abbott <labbott@...hat.com>
> >> ---
> >> This is basically a drop in of what was available as
> >> drivers/staging/android/ion/ion_test.c. Given it has no Ion specific
> >> parts it might be useful as a more general test module. RFC mostly
> >> to see if this is generally useful or not.
> > 
> > We already have a test dma-buf driver, which also handles reservation
> > objects and can create fences to provoke signalling races an all kinds of
> > other fun. It's drivers/gpu/drm/vgem.
> > 
> > If there's anything missing in there, patches very much welcome.
> > -Daniel
> > 
> 
> Thanks for that pointer. It certainly looks more complete vs. allocating
> a platform_device. I'll look and see if there's anything that needs
> extension. Plus this means I can probably delete more code from Ion (woo)

\o/ for less code!

btw for the tests, I think we should really hard to either get them into
kselftests or igt.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ