From patchwork Thu Aug 15 11:59:32 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 2845132 Return-Path: X-Original-To: patchwork-linux-media@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 7B7ACBF546 for ; Thu, 15 Aug 2013 11:59:54 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 96F28201B5 for ; Thu, 15 Aug 2013 11:59:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9E46E203DF for ; Thu, 15 Aug 2013 11:59:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754847Ab3HOL71 (ORCPT ); Thu, 15 Aug 2013 07:59:27 -0400 Received: from mail-ee0-f50.google.com ([74.125.83.50]:43317 "EHLO mail-ee0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752717Ab3HOL7Z (ORCPT ); Thu, 15 Aug 2013 07:59:25 -0400 Received: by mail-ee0-f50.google.com with SMTP id d51so318862eek.37 for ; Thu, 15 Aug 2013 04:59:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=TxqXv46HdRl15LW5D2hLIvA/qGVnoFBP+2/h5kQKrvw=; b=ll/LBWFtEprq2ILClCNHEeoS0yxODa4Va7AtzajL5E98xsMXl5Odx4KlT6sajWMJOV X4H0gdNTVAEKKSdp1iYrw6/WqhFy7t94sDh3l/X6N2V1ZnRBisVd197HpRlmFvjucl7E wpO2H0VMDz5hd/Vw2V5bYWecoY8jvAznfbqvo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=TxqXv46HdRl15LW5D2hLIvA/qGVnoFBP+2/h5kQKrvw=; b=cKih+reLY0EF7/ExhNzGVTC8VhOpEZ4k9JqTaAW+8SCwcqsc+comHawobM8M4q2LlM 16Ls4zX4m/W4d9sUBWMKerB18cdiQbsUbpfsDqrkGHb8lnjYKqr4XgkHbUblO+MkqpDO d9hbdcIl6NXSs7BuWlxWXW5wH8a/rGU15JataCtm9XYxY5F3yzG7zpnhri1WfEzhMthN RZoFxzceuF06mOZObPXLlF6YNTH4W1TzQfpUE6nz3kLLDwGz44YZmRD83MzCOpppa43Y fySHPdT28tRRRnHYbM85dTWwwd30+LeOdAAwLSls/nLJ6AjoKvnIhmfsSbDQIsScLr4A wA2A== X-Gm-Message-State: ALoCoQnV18TPlUZiM0SVhz4o4xxLMOX9X9p5rwCVojyEWdJ7FlJ4HSfAar20Urq57d0HEMrPoRaW X-Received: by 10.15.107.132 with SMTP id cb4mr4459684eeb.54.1376567964268; Thu, 15 Aug 2013 04:59:24 -0700 (PDT) Received: from phenom.ffwll.local (178-83-130-250.dynamic.hispeed.ch. [178.83.130.250]) by mx.google.com with ESMTPSA id p5sm83906086eeg.5.2013.08.15.04.59.22 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 15 Aug 2013 04:59:23 -0700 (PDT) Date: Thu, 15 Aug 2013 13:59:32 +0200 From: Daniel Vetter To: Christopher James Halse Rogers Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, robclark@gmail.com, linux-media@vger.kernel.org Subject: Re: [PATCH] dma-buf: Expose buffer size to userspace Message-ID: <20130815115932.GC776@phenom.ffwll.local> Mail-Followup-To: Christopher James Halse Rogers , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, robclark@gmail.com, linux-media@vger.kernel.org References: <1375683720-4748-1-git-send-email-christopher.halse.rogers@canonical.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1375683720-4748-1-git-send-email-christopher.halse.rogers@canonical.com> X-Operating-System: Linux phenom 3.11.0-rc2+ User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Mon, Aug 05, 2013 at 04:22:00PM +1000, Christopher James Halse Rogers wrote: > Each dma-buf has an associated size and it's reasonable for userspace > to want to know what it is. > > Since userspace already has an fd, expose the size using the > size = lseek(fd, SEEK_END, 0); lseek(fd, SEEK_CUR, 0); > idiom. > > Signed-off-by: Christopher James Halse Rogers Yeah, loosk good to me and rather useful, so (with the dma-buf docs improved as suggested below): Reviewed-by: Daniel Vetter I've also written some small prime tests in igt, so also: Tested-by: Daniel Vetter > --- > > I've run into a point in the radeon DRM userspace where I need the > size of a dma-buf. I could add a radeon-specific mechanism to get that, > but this seems like something that would be more generally useful. > > I'm not entirely sure about supporting both SEEK_END and SEEK_CUR; this > is somewhat of an abuse of lseek, as seeking obviously doesn't make sense. > It's the obivous idiom for getting the size of what's on the other end of a > file descriptor, though. > > I didn't notice anywhere to document this; Documentation/dma-buf-api didn't > seem like the right place. Is there somewhere I've overlooked? I think adding a section about various other userspace interfaces exposed below the mmap support section would be good. Feel free to squash in the belo diff for v2. Cheers, Daniel Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch --- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 0b23261..b3a8aa2 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -407,6 +407,18 @@ Being able to mmap an export dma-buf buffer object has 2 main use-cases: interesting ways depending upong the exporter (if userspace starts depending upon this implicit synchronization). +Other Interfaces Exposed to Userspace on the dma-buf FD +------------------------------------------------------ + +- Since kernel 3.12 the dma-buf FD supports the llseek system call, but only + with offset=0 and whence=SEEK_END|SEEK_SET. SEEK_SET is supported to allowe + the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other + llseek operation will report -EINVAL. + + If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all + cases. Userspace can use this to detect support for discovering the dma-buf + size using llsee. + Miscellaneous notes ------------------- -- Daniel Vetter