| Message ID | 1375969295-18929-23-git-send-email-daniel.vetter@ffwll.ch (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
Daniel Vetter <daniel.vetter@ffwll.ch> writes: > Again only used by a tests in libdrm and by dristat. Nowadays we have > much better tracing tools to get detailed insights into what a drm > driver is doing. And for a simple "does it work" kind of question that > these stats could answer we have plenty of dmesg debug log spew. > > So I don't see any use for this stat gathering complexity at all. > > To be able to gradually drop things start with ripping out the > interfaces to it, here the ioctl. > > To prevent dristat from eating its own stack garbage we can't use the > drm_noop ioctl though, since we need to clear the return data with a > memset. I'm happy to see these two die. Even back in the day we didn't use them. This has been quite a trip down memory lane. Patch 9 typo: s/functinal/functional/ Patch 25 typo: s/loose/lose/ Patches 2, 6-11, 19, 21, 22, 24, 25 are: Reviewed-by: Eric Anholt <eric@anholt.net>
On Thu, Aug 08, 2013 at 05:55:45PM +0200, Eric Anholt wrote: > Daniel Vetter <daniel.vetter@ffwll.ch> writes: > > > Again only used by a tests in libdrm and by dristat. Nowadays we have > > much better tracing tools to get detailed insights into what a drm > > driver is doing. And for a simple "does it work" kind of question that > > these stats could answer we have plenty of dmesg debug log spew. > > > > So I don't see any use for this stat gathering complexity at all. > > > > To be able to gradually drop things start with ripping out the > > interfaces to it, here the ioctl. > > > > To prevent dristat from eating its own stack garbage we can't use the > > drm_noop ioctl though, since we need to clear the return data with a > > memset. > > I'm happy to see these two die. Even back in the day we didn't use > them. > > This has been quite a trip down memory lane. > > Patch 9 typo: s/functinal/functional/ > Patch 25 typo: s/loose/lose/ Fixed. > Patches 2, 6-11, 19, 21, 22, 24, 25 are: > > Reviewed-by: Eric Anholt <eric@anholt.net> Thanks for the review. I've pushed a fixed branch with r-b tags to http://cgit.freedesktop.org/~danvet/drm/log/?h=drm-cleanups Cheers, Daniel
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c index ac8ca5c..cffc7c0 100644 --- a/drivers/gpu/drm/drm_ioctl.c +++ b/drivers/gpu/drm/drm_ioctl.c @@ -257,21 +257,10 @@ int drm_getstats(struct drm_device *dev, void *data, struct drm_file *file_priv) { struct drm_stats *stats = data; - int i; + /* Clear stats to prevent userspace from eating its stack garbage. */ memset(stats, 0, sizeof(*stats)); - for (i = 0; i < dev->counters; i++) { - if (dev->types[i] == _DRM_STAT_LOCK) - stats->data[i].value = - (file_priv->master->lock.hw_lock ? file_priv->master->lock.hw_lock->lock : 0); - else - stats->data[i].value = atomic_read(&dev->counts[i]); - stats->data[i].type = dev->types[i]; - } - - stats->count = dev->counters; - return 0; }
Again only used by a tests in libdrm and by dristat. Nowadays we have much better tracing tools to get detailed insights into what a drm driver is doing. And for a simple "does it work" kind of question that these stats could answer we have plenty of dmesg debug log spew. So I don't see any use for this stat gathering complexity at all. To be able to gradually drop things start with ripping out the interfaces to it, here the ioctl. To prevent dristat from eating its own stack garbage we can't use the drm_noop ioctl though, since we need to clear the return data with a memset. Cc: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> --- drivers/gpu/drm/drm_ioctl.c | 13 +------------ 1 file changed, 1 insertion(+), 12 deletions(-)