From: "Bruno Prémont" <bonbons@linux-vserver.org>
To: James Simmons <jsimmons@infradead.org>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>,
Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Bernie Thompson <bernie@plugable.com>
Subject: Re: [Patch, RFC] Make struct fb_info ref-counted with kref
Date: Wed, 22 Sep 2010 19:35:41 +0000 [thread overview]
Message-ID: <20100922213541.09452849@neptune.home> (raw)
In-Reply-To: <alpine.LFD.2.00.1009222013390.25874@casper.infradead.org>
On Wed, 22 September 2010 James Simmons <jsimmons@infradead.org> wrote:
> > > I have a tree at
> > >
> > > http://git.infradead.org/users/jsimmons/linuxconsole-2.6.git
> > >
> > > but currently fbcon is broken so I'm tracing down the problem.
> >
> > Thanks for the reference to your tree!
> >
> > What's you opinion regarding my changes to fbcon in my RFC patch?
> > Are they ok or would you prefer having fbcon changed to stop peeking
> > at registered_fb list and just operate directly on fb_info everywhere
> > it needs it? (that is let con2fb_map[] point to fb_info instead of
> > indexes into registered_fb? (I have a preference for the second one
> > and will try it out)
>
> I'm aiming to kill off registered_fb. I agree that fb_info should be used
> directly and we can avoid the ref-count. As for con2fb_map that is a
> little more complex.
Refcounting can't be fully avoided on fb side but certainly can be on
(most of) fbcon side (except around fbcon's calls to fbops.fb_open and
fbops.fb_release).
Will attempt the fbcon change as a separate patch my ref-counted fb_info
patch will depend on. (will probably happen during week-end)
Thanks,
Bruno
WARNING: multiple messages have this Message-ID (diff)
From: "Bruno Prémont" <bonbons@linux-vserver.org>
To: James Simmons <jsimmons@infradead.org>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>,
Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Bernie Thompson <bernie@plugable.com>
Subject: Re: [Patch, RFC] Make struct fb_info ref-counted with kref
Date: Wed, 22 Sep 2010 21:35:41 +0200 [thread overview]
Message-ID: <20100922213541.09452849@neptune.home> (raw)
In-Reply-To: <alpine.LFD.2.00.1009222013390.25874@casper.infradead.org>
On Wed, 22 September 2010 James Simmons <jsimmons@infradead.org> wrote:
> > > I have a tree at
> > >
> > > http://git.infradead.org/users/jsimmons/linuxconsole-2.6.git
> > >
> > > but currently fbcon is broken so I'm tracing down the problem.
> >
> > Thanks for the reference to your tree!
> >
> > What's you opinion regarding my changes to fbcon in my RFC patch?
> > Are they ok or would you prefer having fbcon changed to stop peeking
> > at registered_fb list and just operate directly on fb_info everywhere
> > it needs it? (that is let con2fb_map[] point to fb_info instead of
> > indexes into registered_fb? (I have a preference for the second one
> > and will try it out)
>
> I'm aiming to kill off registered_fb. I agree that fb_info should be used
> directly and we can avoid the ref-count. As for con2fb_map that is a
> little more complex.
Refcounting can't be fully avoided on fb side but certainly can be on
(most of) fbcon side (except around fbcon's calls to fbops.fb_open and
fbops.fb_release).
Will attempt the fbcon change as a separate patch my ref-counted fb_info
patch will depend on. (will probably happen during week-end)
Thanks,
Bruno
next prev parent reply other threads:[~2010-09-22 19:35 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
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 [this message]
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=20100922213541.09452849@neptune.home \
--to=bonbons@linux-vserver.org \
--cc=FlorianSchandinat@gmx.de \
--cc=bernie@plugable.com \
--cc=jsimmons@infradead.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.