All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: "Gustavo Padovan" <gustavo@padovan.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org,
	dri-devel@lists.freedesktop.org,
	"Daniel Stone" <daniels@collabora.com>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Riley Andrews" <riandrews@android.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Rob Clark" <robdclark@gmail.com>,
	"Greg Hackmann" <ghackmann@google.com>,
	"John Harrison" <John.C.Harrison@Intel.com>
Subject: Re: [PATCH v3 06/11] staging/android: turn fence_info into a __u64 pointer
Date: Thu, 4 Feb 2016 11:05:42 -0200	[thread overview]
Message-ID: <20160204130542.GA15815@joana> (raw)
In-Reply-To: <56B3207B.50100@linux.intel.com>

2016-02-04 Maarten Lankhorst <maarten.lankhorst@linux.intel.com>:

> Op 03-02-16 om 21:09 schreef Gustavo Padovan:
> > Hi Maarten,
> >
> > 2016-02-03 Maarten Lankhorst <maarten.lankhorst@linux.intel.com>:
> >
> >> Op 03-02-16 om 14:25 schreef Gustavo Padovan:
> >>> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> >>>
> >>> Turn sync_fence_info into __u64 type enable us to extend the struct in the
> >>> future without breaking the ABI.
> >>>
> >>> v2: use type __u64 for fence_info
> >>>
> >>> v3: fix commit message to reflect the v2 change
> >>>
> >>> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> >>> ---
> >>>  drivers/staging/android/sync.c      | 2 +-
> >>>  drivers/staging/android/uapi/sync.h | 2 +-
> >>>  2 files changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> >>> index 2ab0c20..8425457 100644
> >>> --- a/drivers/staging/android/sync.c
> >>> +++ b/drivers/staging/android/sync.c
> >>> @@ -525,7 +525,7 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
> >>>  	if (info->status >= 0)
> >>>  		info->status = !info->status;
> >>>  
> >>> -	len = sizeof(struct sync_file_info);
> >>> +	len = sizeof(struct sync_file_info) - sizeof(__u64);
> >>>  
> >>>  	for (i = 0; i < sync_file->num_fences; ++i) {
> >>>  		struct fence *fence = sync_file->cbs[i].fence;
> >>> diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h
> >>> index a0cf357..e649953 100644
> >>> --- a/drivers/staging/android/uapi/sync.h
> >>> +++ b/drivers/staging/android/uapi/sync.h
> >>> @@ -54,7 +54,7 @@ struct sync_file_info {
> >>>  	char	name[32];
> >>>  	__s32	status;
> >>>  
> >>> -	__u8	sync_fence_info[0];
> >>> +	__u64	sync_fence_info;
> >>>  };
> >>>  
> >>>  #define SYNC_IOC_MAGIC		'>'
> >> This still doesn't do what you expect it to.
> >>
> >> I think this is what you want is for userspace to do:
> >>
> >> struct sync_file_info info;
> >>
> >> info.flags = info.num_fences = 0;
> >> ioctl(fd, SYNC_IOC_FENCE_INFO, &info);
> >> if (info.num_fences) {
> >> info.sync_fence_info = (uintptr)kcalloc(info.num_fences, sizeof(struct sync_fence_info));
> >> ioctl(fd, SYNC_IOC_FENCE_INFO, &info);
> >> }
> >>
> >> Maybe userspace could preallocate the max in advance and set num_fences higher,
> >>
> >> kernel would do something like:
> >>
> >> num_fences = min(info.num_fences, sync->num_fences);
> >> struct sync_fence_info array[num_fences];
> >>
> >> info.num_fences = sync->num_fences;
> >> if (num_fences &&
> >>     copy_to_user((void * __user)(unsigned long)info.sync_fence_info, array, num_fences  * sizeof(array)))
> >>  return -EFAULT;
> > If we are going to call IOCTL twice I would actually have a new IOCTL only
> > to fetch sync_fence_info.
> >
> > First we would call
> >
> > ioctl(fd, SYNC_IOC_FILE_INFO, &info);
> >
> > where info is:
> >
> > struct sync_file_info {    
> >         char    name[32];  
> >         __s32   status;    
> >         __u32   flags;     
> >         __u32   num_fences;
> > };
> >
> > then we would allocate a buffer with
> >
> > size = info.num_fences * sizeof(struct sync_fence_info)
> >
> > and call the new ioctl
> >
> > ioctl(fd, SYNC_IOC_SYNC_FENCE_INFO, sync_fence_info);
> >
> > This looks like a cleaner solution and doesn't break ABI. What do you
> > think?
> I think it's good taste that userspace specifies the size of the buffer it passes, so former feels more clean to me,
> since you need to pass num_fences anyway.

Just to clarify, userspace specifies the size of the buffer in the
solution I proposed. It would be

	size = info.num_fences * sizeof(struct sync_fence_info)

	sync_fence_info = malloc(size);

	ioctl(fd, SYNC_IOC_SYNC_FENCE_INFO, sync_fence_info);

  reply	other threads:[~2016-02-04 13:05 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-03 13:25 [PATCH v3 00/11] android sync framework: clean up IOCTLs and ABI Gustavo Padovan
2016-02-03 13:25 ` Gustavo Padovan
2016-02-03 13:25 ` [PATCH v3 01/11] staging/android: remove SYNC_WAIT ioctl Gustavo Padovan
2016-02-03 13:25   ` Gustavo Padovan
2016-02-03 13:25 ` [PATCH v3 02/11] staging/android: rename sync_pt_info to sync_fence_info Gustavo Padovan
2016-02-03 13:25   ` Gustavo Padovan
2016-02-03 13:25 ` [PATCH v3 03/11] staging/android: rename sync_file_info_data to sync_file_info Gustavo Padovan
2016-02-03 13:25   ` Gustavo Padovan
2016-02-03 13:25 ` [PATCH v3 04/11] staging/android: remove driver_data from struct sync_fence_info Gustavo Padovan
2016-02-03 13:25   ` Gustavo Padovan
2016-02-03 13:25 ` [PATCH v3 05/11] staging/android: remove len field " Gustavo Padovan
2016-02-03 13:25   ` Gustavo Padovan
2016-02-03 13:25 ` [PATCH v3 06/11] staging/android: turn fence_info into a __u64 pointer Gustavo Padovan
2016-02-03 13:25   ` Gustavo Padovan
2016-02-03 14:39   ` Maarten Lankhorst
2016-02-03 14:39     ` Maarten Lankhorst
2016-02-03 20:09     ` Gustavo Padovan
2016-02-03 20:09       ` Gustavo Padovan
2016-02-04  9:57       ` Maarten Lankhorst
2016-02-04  9:57         ` Maarten Lankhorst
2016-02-04 13:05         ` Gustavo Padovan [this message]
2016-02-04 13:23           ` Maarten Lankhorst
2016-02-04 13:23             ` Maarten Lankhorst
2016-02-08  9:01     ` Daniel Vetter
2016-02-08  9:01       ` Daniel Vetter
2016-02-03 13:25 ` [PATCH v3 07/11] staging/android: add num_fences field to struct sync_file_info Gustavo Padovan
2016-02-03 13:25   ` Gustavo Padovan
2016-02-03 13:25 ` [PATCH v3 08/11] staging/android: make info->len return only size of sync_fence_info array Gustavo Padovan
2016-02-03 13:25   ` Gustavo Padovan
2016-02-03 13:25 ` [PATCH v3 09/11] staging/android: rename SYNC_IOC_FENCE_INFO Gustavo Padovan
2016-02-03 13:25   ` Gustavo Padovan
2016-02-03 13:25 ` [PATCH v3 10/11] staging/android: add flags member to sync ioctl structs Gustavo Padovan
2016-02-03 13:25   ` Gustavo Padovan
2016-02-03 13:25 ` [PATCH v3 11/11] staging/android: remove redundant comments on sync_merge_data Gustavo Padovan
2016-02-03 13:25   ` Gustavo Padovan

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=20160204130542.GA15815@joana \
    --to=gustavo.padovan@collabora.co.uk \
    --cc=John.C.Harrison@Intel.com \
    --cc=arve@android.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniels@collabora.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ghackmann@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gustavo@padovan.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=riandrews@android.com \
    --cc=robdclark@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.