From: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
To: "Bruno Prémont" <bonbons@linux-vserver.org>
Cc: linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Bernie Thompson <bernie@plugable.com>
Subject: Re: [Patch, RFC] Make struct fb_info ref-counted with kref
Date: Sun, 19 Sep 2010 16:47:21 +0000 [thread overview]
Message-ID: <4C963E99.9080207@gmx.de> (raw)
In-Reply-To: <20100919172833.14bf291e@neptune.home>
Hi,
Bruno Prémont schrieb:
> For USB-attached (or other hot-(un)pluggable) framebuffers the current
> fbdev infrastructure is not very helpful. Each such driver currently
> needs to perform the ref-counting on its own in .fbops.fb_open and
> .fbops.fb_release callbacks.
I agree. This is a great idea even for non-hot-(un)pluggable framebuffers.
> This patch moves the ref-counting in fbdev infrastructure.
> (drivers have not been adjusted, all those releasing fb_info in
> .fbops.fb_destroy will not work -- patch for those will follow
> later on, all the others will continue to work fine)
>
> API-wise the following changes are done:
> - num_registered_fb and registered_fb variables are no more exported.
> New functions fb_get_registered() and fb_is_registered() replace
> them.
> The only know user of those was fbcon, thus the large diff on fbcon.c
>
> Note: the accesses to registered_fb and num_registered_fb look racy
> as there was not protection at all around them, potentially letting
> register_framebuffer() register two framebuffers on the same minor
> concurrently, fbcon access should have been safe by combination of
> its use of console_semaphore and reaction to events.
> In this patch I combined most of fbcon's accesses to registered_fb
> and num_registered_fb into fb_is_registered(), though I'm not sure
> if the num-check optimization is worth to keep or its check should
> be put into a separate function.
>
> - framebuffer_release() is mapped to fb_put() but will go away
> when converting drivers
>
> Reference count for fb_info can be increased with fb_get(fb_info) and
> later released with fb_put(fb_info).
>
>
> If you have concerns regarding the API changes, please let me know.
Uhm, I'm not really happy with what we count. With the old method you mentioned
we ref-counted framebuffer users, after your patch it's more counting users +
uses. This might be okay as we usually are interested whether the ref_count is 0
or not but it doesn't look right if we modify the refcount during nearly every
framebuffer operation. Wouldn't it be sufficient to do the refcounting in
fb_open & fb_release operation + in fbcon where open&release are done?
> diff --git a/drivers/video/fbsysfs.c b/drivers/video/fbsysfs.c
> index 0a08f13..be5f342 100644
> --- a/drivers/video/fbsysfs.c
> +++ b/drivers/video/fbsysfs.c
> @@ -58,6 +58,7 @@ struct fb_info *framebuffer_alloc(size_t size, struct device *dev)
> info->par = p + fb_info_size;
>
> info->device = dev;
> + kref_init(&info->refcount);
As far as I know there exist framebuffer drivers which do not call
framebuffer_alloc but contain their own fb_info. I guess these would be broken
as well.
Thanks,
Florian Tobias Schandinat
WARNING: multiple messages have this Message-ID (diff)
From: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
To: "Bruno Prémont" <bonbons@linux-vserver.org>
Cc: linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Bernie Thompson <bernie@plugable.com>
Subject: Re: [Patch, RFC] Make struct fb_info ref-counted with kref
Date: Sun, 19 Sep 2010 18:47:21 +0200 [thread overview]
Message-ID: <4C963E99.9080207@gmx.de> (raw)
In-Reply-To: <20100919172833.14bf291e@neptune.home>
Hi,
Bruno Prémont schrieb:
> For USB-attached (or other hot-(un)pluggable) framebuffers the current
> fbdev infrastructure is not very helpful. Each such driver currently
> needs to perform the ref-counting on its own in .fbops.fb_open and
> .fbops.fb_release callbacks.
I agree. This is a great idea even for non-hot-(un)pluggable framebuffers.
> This patch moves the ref-counting in fbdev infrastructure.
> (drivers have not been adjusted, all those releasing fb_info in
> .fbops.fb_destroy will not work -- patch for those will follow
> later on, all the others will continue to work fine)
>
> API-wise the following changes are done:
> - num_registered_fb and registered_fb variables are no more exported.
> New functions fb_get_registered() and fb_is_registered() replace
> them.
> The only know user of those was fbcon, thus the large diff on fbcon.c
>
> Note: the accesses to registered_fb and num_registered_fb look racy
> as there was not protection at all around them, potentially letting
> register_framebuffer() register two framebuffers on the same minor
> concurrently, fbcon access should have been safe by combination of
> its use of console_semaphore and reaction to events.
> In this patch I combined most of fbcon's accesses to registered_fb
> and num_registered_fb into fb_is_registered(), though I'm not sure
> if the num-check optimization is worth to keep or its check should
> be put into a separate function.
>
> - framebuffer_release() is mapped to fb_put() but will go away
> when converting drivers
>
> Reference count for fb_info can be increased with fb_get(fb_info) and
> later released with fb_put(fb_info).
>
>
> If you have concerns regarding the API changes, please let me know.
Uhm, I'm not really happy with what we count. With the old method you mentioned
we ref-counted framebuffer users, after your patch it's more counting users +
uses. This might be okay as we usually are interested whether the ref_count is 0
or not but it doesn't look right if we modify the refcount during nearly every
framebuffer operation. Wouldn't it be sufficient to do the refcounting in
fb_open & fb_release operation + in fbcon where open&release are done?
> diff --git a/drivers/video/fbsysfs.c b/drivers/video/fbsysfs.c
> index 0a08f13..be5f342 100644
> --- a/drivers/video/fbsysfs.c
> +++ b/drivers/video/fbsysfs.c
> @@ -58,6 +58,7 @@ struct fb_info *framebuffer_alloc(size_t size, struct device *dev)
> info->par = p + fb_info_size;
>
> info->device = dev;
> + kref_init(&info->refcount);
As far as I know there exist framebuffer drivers which do not call
framebuffer_alloc but contain their own fb_info. I guess these would be broken
as well.
Thanks,
Florian Tobias Schandinat
next prev parent reply other threads:[~2010-09-19 16:47 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-19 15:28 [Patch, RFC] Make struct fb_info ref-counted with kref Bruno Prémont
2010-09-19 15:28 ` Bruno Prémont
2010-09-19 16:47 ` Florian Tobias Schandinat [this message]
2010-09-19 16:47 ` Florian Tobias Schandinat
2010-09-19 17:02 ` Bruno Prémont
2010-09-19 17:02 ` Bruno Prémont
2010-09-20 19:05 ` Florian Tobias Schandinat
2010-09-20 19:05 ` Florian Tobias Schandinat
2010-09-20 19:32 ` Bruno Prémont
2010-09-20 19:32 ` Bruno Prémont
2010-09-20 20:08 ` Florian Tobias Schandinat
2010-09-20 20:08 ` Florian Tobias Schandinat
2010-09-20 20:36 ` Bruno Prémont
2010-09-20 20:36 ` Bruno Prémont
2010-09-20 22:28 ` Florian Tobias Schandinat
2010-09-20 22:28 ` Florian Tobias Schandinat
2010-09-21 5:56 ` Bruno Prémont
2010-09-21 5:56 ` Bruno Prémont
2010-09-21 6:39 ` Florian Tobias Schandinat
2010-09-21 6:39 ` Florian Tobias Schandinat
2010-09-21 7:02 ` Bruno Prémont
2010-09-21 7:02 ` Bruno Prémont
2010-09-22 17:31 ` James Simmons
2010-09-22 17:31 ` James Simmons
2010-09-22 18:39 ` Bruno Prémont
2010-09-22 18:39 ` Bruno Prémont
2010-09-22 19:14 ` James Simmons
2010-09-22 19:14 ` James Simmons
2010-09-22 19:35 ` Bruno Prémont
2010-09-22 19:35 ` Bruno Prémont
2010-09-20 19:34 ` Guennadi Liakhovetski
2010-09-20 19:34 ` Guennadi Liakhovetski
2010-09-20 20:14 ` Bruno Prémont
2010-09-20 20:14 ` Bruno Prémont
2010-09-20 20:27 ` Guennadi Liakhovetski
2010-09-20 20:27 ` Guennadi Liakhovetski
2010-09-21 10:44 ` Michel Dänzer
2010-09-21 10:44 ` Michel Dänzer
2010-09-20 8:27 ` Geert Uytterhoeven
2010-09-20 8:27 ` Geert Uytterhoeven
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=4C963E99.9080207@gmx.de \
--to=florianschandinat@gmx.de \
--cc=bernie@plugable.com \
--cc=bonbons@linux-vserver.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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.