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  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:	Sat, 14 Dec 2013 13:16:21 +0100
From:	Thierry Reding <thierry.reding@...il.com>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Sumit Semwal <sumit.semwal@...aro.org>,
	dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] dma-buf: Implement test module

On Thu, Dec 12, 2013 at 06:04:13PM -0800, Greg Kroah-Hartman wrote:
> On Thu, Dec 12, 2013 at 03:36:29PM +0100, Thierry Reding wrote:
> > This is a simple test module that can be used to allocate, export and
> > delete DMA-BUF objects. It can be used to test DMA-BUF sharing in
> > systems that lack a real second driver.
> > 
> > Signed-off-by: Thierry Reding <treding@...dia.com>
> > ---
> >  drivers/base/Kconfig        |   4 +
> >  drivers/base/Makefile       |   1 +
> >  drivers/base/dma-buf-test.c | 308 ++++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 313 insertions(+)
> >  create mode 100644 drivers/base/dma-buf-test.c
> > 
> > diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> > index e373671652b0..bed2abb9491b 100644
> > --- a/drivers/base/Kconfig
> > +++ b/drivers/base/Kconfig
> > @@ -200,6 +200,10 @@ config DMA_SHARED_BUFFER
> >  	  APIs extension; the file's descriptor can then be passed on to other
> >  	  driver.
> >  
> > +config DMA_BUF_TEST
> > +	tristate "DMA-BUF test module"
> > +	depends on DMA_SHARED_BUFFER
> 
> We need some good documentation here.

I agree. The description should go into more details about what exactly
this is meant to address.

> > > +static struct miscdevice dmabuf_device = {
> > +	.minor = 128,
> 
> Why did you pick this minor?  Why not just make it dynamic?

It seemed like minors are statically allocated for miscdevice and 128
seemed to be as good as any. The tentative plan was to go through the
official way of having one allocated as explained in the comment in
include/linux/miscdevice.h.

Reading that comment again, there's MISC_DYNAMIC_MINOR, which I guess
would be appropriate here. Chances are that if you want to test DMA-BUF
you'll have a reasonably modern userspace that will create the device
dynamically.

Alternatively I guess I could instead turn this into a more full-fledged
cdev and do the whole alloc_chrdev_region() dance. Although that will
only allocate the major dynamically.

I'm not aware of any function that just allocates a single major/minor
pair completely dynamically. Is there one that you could point me to?

Thierry

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists