Re: [PATCH 10/30] staging: sync: Export sync API symbols
On Fri, Mar 1, 2013 at 12:21 AM, Erik Gilling wrote: > On Thu, Feb 28, 2013 at 7:59 PM, John Stultz wrote: >> Given its the sync driver, its most obvious choice, but I agree its likely >> to collide with filesystem related or other sync_ named functions that don't >> have a subsystem prefix. >> >> Any suggestions? >> >> The only good alternative I can think of is that in some private >> conversations with DanielV, he referred to Android using "sync-points". >> >> Erik: Would syncpoint_ be an ok prefix? Or do you have other ideas? > > syncpoint would be semantically weird when you end up with struct > syncpoint_pt. I'm open to suggestions as long as it works with > _pt, _timeline, and _fence. I'll ask around the office > and see if someone has a good idea. Colin Cross pointed out that this is limited to sync_fence_*, sync_pt_*, and sync_timeline_* and not sync_* so it's much less likely to have naming collisions. Cheers, Erik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/30] staging: sync: Export sync API symbols
On Fri, Mar 1, 2013 at 5:55 AM, Greg KH wrote: > On Fri, Mar 01, 2013 at 12:21:24AM -0800, Erik Gilling wrote: >> As John pointed out, the exynos and msm display and code uses them. I >> know nvidia is working on adding suport to their tegra tree. My knee >> jerk reaction is to make the export as permissible as possible. That >> being said, all of the ARM SoC vendors I've worked with have GPL >> kernel drivers even if their user space is closed. I'll reach out to >> them and ask for their opinions. Are there any issues with keeping >> them EXPORT_SYMBOL? > > There's no "issues", it's just that it is preferred by some people and > companies to add new symbols to the kernel in this manner. It's really > up to you / Google as you are the ones contributing the code. Ok. Lets keep it EXPORT_SYMBOL then. Cheers, Erik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/30] staging: sync: Export sync API symbols
On Fri, Mar 01, 2013 at 12:21:24AM -0800, Erik Gilling wrote: > On Thu, Feb 28, 2013 at 7:59 PM, John Stultz wrote: > >> Also, EXPORT_SYMBOL_GPL() perhaps? > >> > >> And who is using these exports? > > > > > > From some quick git grepping... > > As John pointed out, the exynos and msm display and code uses them. I > know nvidia is working on adding suport to their tegra tree. My knee > jerk reaction is to make the export as permissible as possible. That > being said, all of the ARM SoC vendors I've worked with have GPL > kernel drivers even if their user space is closed. I'll reach out to > them and ask for their opinions. Are there any issues with keeping > them EXPORT_SYMBOL? There's no "issues", it's just that it is preferred by some people and companies to add new symbols to the kernel in this manner. It's really up to you / Google as you are the ones contributing the code. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/30] staging: sync: Export sync API symbols
On Thu, Feb 28, 2013 at 7:59 PM, John Stultz wrote: >>> +EXPORT_SYMBOL(sync_timeline_create); >> >> As these are now global, should they be a bit more "specific"? "sync_" >> seems pretty broad. > > > Given its the sync driver, its most obvious choice, but I agree its likely > to collide with filesystem related or other sync_ named functions that don't > have a subsystem prefix. > > Any suggestions? > > The only good alternative I can think of is that in some private > conversations with DanielV, he referred to Android using "sync-points". > > Erik: Would syncpoint_ be an ok prefix? Or do you have other ideas? syncpoint would be semantically weird when you end up with struct syncpoint_pt. I'm open to suggestions as long as it works with _pt, _timeline, and _fence. I'll ask around the office and see if someone has a good idea. >> Also, EXPORT_SYMBOL_GPL() perhaps? >> >> And who is using these exports? > > > From some quick git grepping... As John pointed out, the exynos and msm display and code uses them. I know nvidia is working on adding suport to their tegra tree. My knee jerk reaction is to make the export as permissible as possible. That being said, all of the ARM SoC vendors I've worked with have GPL kernel drivers even if their user space is closed. I'll reach out to them and ask for their opinions. Are there any issues with keeping them EXPORT_SYMBOL? Cheers, Erik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/30] staging: sync: Export sync API symbols
On Thu, Feb 28, 2013 at 7:59 PM, John Stultz john.stu...@linaro.org wrote: +EXPORT_SYMBOL(sync_timeline_create); As these are now global, should they be a bit more specific? sync_ seems pretty broad. Given its the sync driver, its most obvious choice, but I agree its likely to collide with filesystem related or other sync_ named functions that don't have a subsystem prefix. Any suggestions? The only good alternative I can think of is that in some private conversations with DanielV, he referred to Android using sync-points. Erik: Would syncpoint_ be an ok prefix? Or do you have other ideas? syncpoint would be semantically weird when you end up with struct syncpoint_pt. I'm open to suggestions as long as it works with _pt, _timeline, and _fence. I'll ask around the office and see if someone has a good idea. Also, EXPORT_SYMBOL_GPL() perhaps? And who is using these exports? From some quick git grepping... As John pointed out, the exynos and msm display and code uses them. I know nvidia is working on adding suport to their tegra tree. My knee jerk reaction is to make the export as permissible as possible. That being said, all of the ARM SoC vendors I've worked with have GPL kernel drivers even if their user space is closed. I'll reach out to them and ask for their opinions. Are there any issues with keeping them EXPORT_SYMBOL? Cheers, Erik -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/30] staging: sync: Export sync API symbols
On Fri, Mar 01, 2013 at 12:21:24AM -0800, Erik Gilling wrote: On Thu, Feb 28, 2013 at 7:59 PM, John Stultz john.stu...@linaro.org wrote: Also, EXPORT_SYMBOL_GPL() perhaps? And who is using these exports? From some quick git grepping... As John pointed out, the exynos and msm display and code uses them. I know nvidia is working on adding suport to their tegra tree. My knee jerk reaction is to make the export as permissible as possible. That being said, all of the ARM SoC vendors I've worked with have GPL kernel drivers even if their user space is closed. I'll reach out to them and ask for their opinions. Are there any issues with keeping them EXPORT_SYMBOL? There's no issues, it's just that it is preferred by some people and companies to add new symbols to the kernel in this manner. It's really up to you / Google as you are the ones contributing the code. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/30] staging: sync: Export sync API symbols
On Fri, Mar 1, 2013 at 5:55 AM, Greg KH gre...@linuxfoundation.org wrote: On Fri, Mar 01, 2013 at 12:21:24AM -0800, Erik Gilling wrote: As John pointed out, the exynos and msm display and code uses them. I know nvidia is working on adding suport to their tegra tree. My knee jerk reaction is to make the export as permissible as possible. That being said, all of the ARM SoC vendors I've worked with have GPL kernel drivers even if their user space is closed. I'll reach out to them and ask for their opinions. Are there any issues with keeping them EXPORT_SYMBOL? There's no issues, it's just that it is preferred by some people and companies to add new symbols to the kernel in this manner. It's really up to you / Google as you are the ones contributing the code. Ok. Lets keep it EXPORT_SYMBOL then. Cheers, Erik -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/30] staging: sync: Export sync API symbols
On Fri, Mar 1, 2013 at 12:21 AM, Erik Gilling konk...@android.com wrote: On Thu, Feb 28, 2013 at 7:59 PM, John Stultz john.stu...@linaro.org wrote: Given its the sync driver, its most obvious choice, but I agree its likely to collide with filesystem related or other sync_ named functions that don't have a subsystem prefix. Any suggestions? The only good alternative I can think of is that in some private conversations with DanielV, he referred to Android using sync-points. Erik: Would syncpoint_ be an ok prefix? Or do you have other ideas? syncpoint would be semantically weird when you end up with struct syncpoint_pt. I'm open to suggestions as long as it works with _pt, _timeline, and _fence. I'll ask around the office and see if someone has a good idea. Colin Cross pointed out that this is limited to sync_fence_*, sync_pt_*, and sync_timeline_* and not sync_* so it's much less likely to have naming collisions. Cheers, Erik -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/30] staging: sync: Export sync API symbols
On 02/28/2013 06:00 PM, Greg KH wrote:
On Thu, Feb 28, 2013 at 04:43:06PM -0800, John Stultz wrote:
From: Erik Gilling
This is needed to allow modules to link against the sync subsystem
Cc: Maarten Lankhorst
Cc: Erik Gilling
Cc: Daniel Vetter
Cc: Rob Clark
Cc: Sumit Semwal
Cc: Greg KH
Cc: dri-de...@lists.freedesktop.org
Cc: Android Kernel Team
Signed-off-by: Erik Gilling
Signed-off-by: John Stultz
---
drivers/staging/android/sync.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 54f84d9..6739a84 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -15,6 +15,7 @@
*/
#include
+#include
#include
#include
#include
@@ -64,6 +65,7 @@ struct sync_timeline *sync_timeline_create(const struct
sync_timeline_ops *ops,
return obj;
}
+EXPORT_SYMBOL(sync_timeline_create);
As these are now global, should they be a bit more "specific"? "sync_"
seems pretty broad.
Given its the sync driver, its most obvious choice, but I agree its
likely to collide with filesystem related or other sync_ named functions
that don't have a subsystem prefix.
Any suggestions?
The only good alternative I can think of is that in some private
conversations with DanielV, he referred to Android using "sync-points".
Erik: Would syncpoint_ be an ok prefix? Or do you have other ideas?
Also, EXPORT_SYMBOL_GPL() perhaps?
And who is using these exports?
From some quick git grepping...
In the android exynos tree:
https://android.googlesource.com/kernel/exynos.git
android-exynos-manta-3.4-jb-mr1.1
drivers/gpu/arm/t6xx/kbase/src/linux/mali_kbase_sync.c: tl =
sync_timeline_creat
drivers/media/video/videobuf2-core.c: q->timeline =
sw_sync_timeline_create(q-
drivers/video/s3c-fb.c: sfb->timeline = sw_sync_timeline_create("s3c-fb");
In the android msm tree:
https://android.googlesource.com/kernel/msm.git
android-msm-mako-3.4-jb-mr1.1
drivers/gpu/msm/kgsl_sync.c:context->timeline =
sync_timeline_create(_s
drivers/video/msm/msm_fb.c: mfd->timeline =
sw_sync_timeline_create(
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/30] staging: sync: Export sync API symbols
On Thu, Feb 28, 2013 at 04:43:06PM -0800, John Stultz wrote: > From: Erik Gilling > > This is needed to allow modules to link against the sync subsystem > > Cc: Maarten Lankhorst > Cc: Erik Gilling > Cc: Daniel Vetter > Cc: Rob Clark > Cc: Sumit Semwal > Cc: Greg KH > Cc: dri-de...@lists.freedesktop.org > Cc: Android Kernel Team > Signed-off-by: Erik Gilling > Signed-off-by: John Stultz > --- > drivers/staging/android/sync.c | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c > index 54f84d9..6739a84 100644 > --- a/drivers/staging/android/sync.c > +++ b/drivers/staging/android/sync.c > @@ -15,6 +15,7 @@ > */ > > #include > +#include > #include > #include > #include > @@ -64,6 +65,7 @@ struct sync_timeline *sync_timeline_create(const struct > sync_timeline_ops *ops, > > return obj; > } > +EXPORT_SYMBOL(sync_timeline_create); As these are now global, should they be a bit more "specific"? "sync_" seems pretty broad. Also, EXPORT_SYMBOL_GPL() perhaps? And who is using these exports? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/30] staging: sync: Export sync API symbols
From: Erik Gilling
This is needed to allow modules to link against the sync subsystem
Cc: Maarten Lankhorst
Cc: Erik Gilling
Cc: Daniel Vetter
Cc: Rob Clark
Cc: Sumit Semwal
Cc: Greg KH
Cc: dri-de...@lists.freedesktop.org
Cc: Android Kernel Team
Signed-off-by: Erik Gilling
Signed-off-by: John Stultz
---
drivers/staging/android/sync.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 54f84d9..6739a84 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -15,6 +15,7 @@
*/
#include
+#include
#include
#include
#include
@@ -64,6 +65,7 @@ struct sync_timeline *sync_timeline_create(const struct
sync_timeline_ops *ops,
return obj;
}
+EXPORT_SYMBOL(sync_timeline_create);
static void sync_timeline_free(struct sync_timeline *obj)
{
@@ -94,6 +96,7 @@ void sync_timeline_destroy(struct sync_timeline *obj)
else
sync_timeline_signal(obj);
}
+EXPORT_SYMBOL(sync_timeline_destroy);
static void sync_timeline_add_pt(struct sync_timeline *obj, struct sync_pt *pt)
{
@@ -152,6 +155,7 @@ void sync_timeline_signal(struct sync_timeline *obj)
sync_fence_signal_pt(pt);
}
}
+EXPORT_SYMBOL(sync_timeline_signal);
struct sync_pt *sync_pt_create(struct sync_timeline *parent, int size)
{
@@ -169,6 +173,7 @@ struct sync_pt *sync_pt_create(struct sync_timeline
*parent, int size)
return pt;
}
+EXPORT_SYMBOL(sync_pt_create);
void sync_pt_free(struct sync_pt *pt)
{
@@ -179,6 +184,7 @@ void sync_pt_free(struct sync_pt *pt)
kfree(pt);
}
+EXPORT_SYMBOL(sync_pt_free);
/* call with pt->parent->active_list_lock held */
static int _sync_pt_has_signaled(struct sync_pt *pt)
@@ -284,6 +290,7 @@ struct sync_fence *sync_fence_create(const char *name,
struct sync_pt *pt)
return fence;
}
+EXPORT_SYMBOL(sync_fence_create);
static int sync_fence_copy_pts(struct sync_fence *dst, struct sync_fence *src)
{
@@ -331,16 +338,19 @@ err:
fput(file);
return NULL;
}
+EXPORT_SYMBOL(sync_fence_fdget);
void sync_fence_put(struct sync_fence *fence)
{
fput(fence->file);
}
+EXPORT_SYMBOL(sync_fence_put);
void sync_fence_install(struct sync_fence *fence, int fd)
{
fd_install(fd, fence->file);
}
+EXPORT_SYMBOL(sync_fence_install);
static int sync_fence_get_status(struct sync_fence *fence)
{
@@ -388,6 +398,7 @@ err:
kfree(fence);
return NULL;
}
+EXPORT_SYMBOL(sync_fence_merge);
static void sync_fence_signal_pt(struct sync_pt *pt)
{
@@ -447,6 +458,7 @@ out:
return err;
}
+EXPORT_SYMBOL(sync_fence_wait_async);
int sync_fence_cancel_async(struct sync_fence *fence,
struct sync_fence_waiter *waiter)
@@ -475,6 +487,7 @@ int sync_fence_cancel_async(struct sync_fence *fence,
spin_unlock_irqrestore(>waiter_list_lock, flags);
return ret;
}
+EXPORT_SYMBOL(sync_fence_cancel_async);
int sync_fence_wait(struct sync_fence *fence, long timeout)
{
@@ -500,6 +513,7 @@ int sync_fence_wait(struct sync_fence *fence, long timeout)
return 0;
}
+EXPORT_SYMBOL(sync_fence_wait);
static int sync_fence_release(struct inode *inode, struct file *file)
{
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/30] staging: sync: Export sync API symbols
From: Erik Gilling konk...@android.com
This is needed to allow modules to link against the sync subsystem
Cc: Maarten Lankhorst maarten.lankho...@canonical.com
Cc: Erik Gilling konk...@android.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Rob Clark robcl...@gmail.com
Cc: Sumit Semwal sumit.sem...@linaro.org
Cc: Greg KH gre...@linuxfoundation.org
Cc: dri-de...@lists.freedesktop.org
Cc: Android Kernel Team kernel-t...@android.com
Signed-off-by: Erik Gilling konk...@android.com
Signed-off-by: John Stultz john.stu...@linaro.org
---
drivers/staging/android/sync.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 54f84d9..6739a84 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -15,6 +15,7 @@
*/
#include linux/debugfs.h
+#include linux/export.h
#include linux/file.h
#include linux/fs.h
#include linux/kernel.h
@@ -64,6 +65,7 @@ struct sync_timeline *sync_timeline_create(const struct
sync_timeline_ops *ops,
return obj;
}
+EXPORT_SYMBOL(sync_timeline_create);
static void sync_timeline_free(struct sync_timeline *obj)
{
@@ -94,6 +96,7 @@ void sync_timeline_destroy(struct sync_timeline *obj)
else
sync_timeline_signal(obj);
}
+EXPORT_SYMBOL(sync_timeline_destroy);
static void sync_timeline_add_pt(struct sync_timeline *obj, struct sync_pt *pt)
{
@@ -152,6 +155,7 @@ void sync_timeline_signal(struct sync_timeline *obj)
sync_fence_signal_pt(pt);
}
}
+EXPORT_SYMBOL(sync_timeline_signal);
struct sync_pt *sync_pt_create(struct sync_timeline *parent, int size)
{
@@ -169,6 +173,7 @@ struct sync_pt *sync_pt_create(struct sync_timeline
*parent, int size)
return pt;
}
+EXPORT_SYMBOL(sync_pt_create);
void sync_pt_free(struct sync_pt *pt)
{
@@ -179,6 +184,7 @@ void sync_pt_free(struct sync_pt *pt)
kfree(pt);
}
+EXPORT_SYMBOL(sync_pt_free);
/* call with pt-parent-active_list_lock held */
static int _sync_pt_has_signaled(struct sync_pt *pt)
@@ -284,6 +290,7 @@ struct sync_fence *sync_fence_create(const char *name,
struct sync_pt *pt)
return fence;
}
+EXPORT_SYMBOL(sync_fence_create);
static int sync_fence_copy_pts(struct sync_fence *dst, struct sync_fence *src)
{
@@ -331,16 +338,19 @@ err:
fput(file);
return NULL;
}
+EXPORT_SYMBOL(sync_fence_fdget);
void sync_fence_put(struct sync_fence *fence)
{
fput(fence-file);
}
+EXPORT_SYMBOL(sync_fence_put);
void sync_fence_install(struct sync_fence *fence, int fd)
{
fd_install(fd, fence-file);
}
+EXPORT_SYMBOL(sync_fence_install);
static int sync_fence_get_status(struct sync_fence *fence)
{
@@ -388,6 +398,7 @@ err:
kfree(fence);
return NULL;
}
+EXPORT_SYMBOL(sync_fence_merge);
static void sync_fence_signal_pt(struct sync_pt *pt)
{
@@ -447,6 +458,7 @@ out:
return err;
}
+EXPORT_SYMBOL(sync_fence_wait_async);
int sync_fence_cancel_async(struct sync_fence *fence,
struct sync_fence_waiter *waiter)
@@ -475,6 +487,7 @@ int sync_fence_cancel_async(struct sync_fence *fence,
spin_unlock_irqrestore(fence-waiter_list_lock, flags);
return ret;
}
+EXPORT_SYMBOL(sync_fence_cancel_async);
int sync_fence_wait(struct sync_fence *fence, long timeout)
{
@@ -500,6 +513,7 @@ int sync_fence_wait(struct sync_fence *fence, long timeout)
return 0;
}
+EXPORT_SYMBOL(sync_fence_wait);
static int sync_fence_release(struct inode *inode, struct file *file)
{
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/30] staging: sync: Export sync API symbols
On Thu, Feb 28, 2013 at 04:43:06PM -0800, John Stultz wrote: From: Erik Gilling konk...@android.com This is needed to allow modules to link against the sync subsystem Cc: Maarten Lankhorst maarten.lankho...@canonical.com Cc: Erik Gilling konk...@android.com Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: Rob Clark robcl...@gmail.com Cc: Sumit Semwal sumit.sem...@linaro.org Cc: Greg KH gre...@linuxfoundation.org Cc: dri-de...@lists.freedesktop.org Cc: Android Kernel Team kernel-t...@android.com Signed-off-by: Erik Gilling konk...@android.com Signed-off-by: John Stultz john.stu...@linaro.org --- drivers/staging/android/sync.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c index 54f84d9..6739a84 100644 --- a/drivers/staging/android/sync.c +++ b/drivers/staging/android/sync.c @@ -15,6 +15,7 @@ */ #include linux/debugfs.h +#include linux/export.h #include linux/file.h #include linux/fs.h #include linux/kernel.h @@ -64,6 +65,7 @@ struct sync_timeline *sync_timeline_create(const struct sync_timeline_ops *ops, return obj; } +EXPORT_SYMBOL(sync_timeline_create); As these are now global, should they be a bit more specific? sync_ seems pretty broad. Also, EXPORT_SYMBOL_GPL() perhaps? And who is using these exports? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/30] staging: sync: Export sync API symbols
On 02/28/2013 06:00 PM, Greg KH wrote: On Thu, Feb 28, 2013 at 04:43:06PM -0800, John Stultz wrote: From: Erik Gilling konk...@android.com This is needed to allow modules to link against the sync subsystem Cc: Maarten Lankhorst maarten.lankho...@canonical.com Cc: Erik Gilling konk...@android.com Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: Rob Clark robcl...@gmail.com Cc: Sumit Semwal sumit.sem...@linaro.org Cc: Greg KH gre...@linuxfoundation.org Cc: dri-de...@lists.freedesktop.org Cc: Android Kernel Team kernel-t...@android.com Signed-off-by: Erik Gilling konk...@android.com Signed-off-by: John Stultz john.stu...@linaro.org --- drivers/staging/android/sync.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c index 54f84d9..6739a84 100644 --- a/drivers/staging/android/sync.c +++ b/drivers/staging/android/sync.c @@ -15,6 +15,7 @@ */ #include linux/debugfs.h +#include linux/export.h #include linux/file.h #include linux/fs.h #include linux/kernel.h @@ -64,6 +65,7 @@ struct sync_timeline *sync_timeline_create(const struct sync_timeline_ops *ops, return obj; } +EXPORT_SYMBOL(sync_timeline_create); As these are now global, should they be a bit more specific? sync_ seems pretty broad. Given its the sync driver, its most obvious choice, but I agree its likely to collide with filesystem related or other sync_ named functions that don't have a subsystem prefix. Any suggestions? The only good alternative I can think of is that in some private conversations with DanielV, he referred to Android using sync-points. Erik: Would syncpoint_ be an ok prefix? Or do you have other ideas? Also, EXPORT_SYMBOL_GPL() perhaps? And who is using these exports? From some quick git grepping... In the android exynos tree: https://android.googlesource.com/kernel/exynos.git android-exynos-manta-3.4-jb-mr1.1 drivers/gpu/arm/t6xx/kbase/src/linux/mali_kbase_sync.c: tl = sync_timeline_creat drivers/media/video/videobuf2-core.c: q-timeline = sw_sync_timeline_create(q- drivers/video/s3c-fb.c: sfb-timeline = sw_sync_timeline_create(s3c-fb); In the android msm tree: https://android.googlesource.com/kernel/msm.git android-msm-mako-3.4-jb-mr1.1 drivers/gpu/msm/kgsl_sync.c:context-timeline = sync_timeline_create(kgsl_s drivers/video/msm/msm_fb.c: mfd-timeline = sw_sync_timeline_create( thanks -john -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
