From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] dma-buf: Implement test module
Date: Sat, 14 Dec 2013 11:26:11 -0800 [thread overview]
Message-ID: <20131214192611.GA23651@kroah.com> (raw)
In-Reply-To: <20131214121620.GA17467@mithrandir>
On Sat, Dec 14, 2013 at 01:16:21PM +0100, Thierry Reding wrote:
> 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@nvidia.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.
No, just use a dynamic misc device and all will be fine. Bonus is that
you can create multiple misc devices if you ever really need to in the
future, with no need to change much code at all (i.e. no chrdev crud.)
> 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?
Nope, that's what misc devices are for :)
greg k-h
prev parent reply other threads:[~2013-12-14 19:27 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-12 14:36 [RFC] dma-buf: Implement test module Thierry Reding
2013-12-12 14:42 ` Thierry Reding
2013-12-13 2:02 ` Greg Kroah-Hartman
2013-12-14 12:32 ` Thierry Reding
2014-03-25 16:17 ` Thierry Reding
2014-03-25 18:01 ` Sam Ravnborg
2014-03-26 8:32 ` Thierry Reding
2014-07-10 9:55 ` Thierry Reding
2014-07-11 20:33 ` Sam Ravnborg
2013-12-12 14:53 ` Daniel Vetter
2013-12-12 15:08 ` Thierry Reding
2013-12-12 19:34 ` Thomas Hellstrom
2013-12-12 22:30 ` Daniel Vetter
2013-12-14 12:37 ` Thierry Reding
2013-12-14 12:47 ` Thomas Hellstrom
2013-12-14 13:02 ` Rob Clark
2013-12-14 13:10 ` Thomas Hellstrom
2013-12-14 16:05 ` Daniel Vetter
2013-12-14 12:39 ` Thierry Reding
2013-12-13 2:04 ` Greg Kroah-Hartman
2013-12-14 12:16 ` Thierry Reding
2013-12-14 17:42 ` Daniel Vetter
2013-12-14 19:26 ` Greg Kroah-Hartman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131214192611.GA23651@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sumit.semwal@linaro.org \
--cc=thierry.reding@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox