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);
next prev parent reply other threads:[~2016-02-04 13:05 UTC|newest]
Thread overview: 18+ 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 ` [PATCH v3 01/11] staging/android: remove SYNC_WAIT ioctl 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 ` [PATCH v3 03/11] staging/android: rename sync_file_info_data to sync_file_info 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 ` [PATCH v3 05/11] staging/android: remove len field " 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 14:39 ` Maarten Lankhorst
2016-02-03 20:09 ` Gustavo Padovan
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-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 ` [PATCH v3 08/11] staging/android: make info->len return only size of sync_fence_info array 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 ` [PATCH v3 10/11] staging/android: add flags member to sync ioctl structs Gustavo Padovan
2016-02-03 13:25 ` [PATCH v3 11/11] staging/android: remove redundant comments on sync_merge_data 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).