lkml.org 
[lkml]   [2015]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Re: [PATCH v4 3/3] vt: fix console lock vs. kernfs s_active lock order
On 12/16/2014 09:42 AM, Daniel Vetter wrote:
> On Tue, Dec 16, 2014 at 6:15 PM, Peter Hurley <peter@hurleysoftware.com> wrote:
>> On 12/16/2014 11:22 AM, Imre Deak wrote:
>>> On Tue, 2014-12-16 at 10:00 -0500, Peter Hurley wrote:
>>>> Fine. Just another expedient fix piled on top of other expedient fixes
>>>> that go back past 3.9 with no end in sight.
>>>
>>> I'm also happy to look into narrowing down the scope of console_lock in
>>> fbdev/fbcon as was suggested. But doing that as a follow-up to this
>>> change still makes sense to me since it will take more time and have the
>>> risk of regressions that are not related to what this change fixes.
>>
>> I apologize for my tone. I'm not blaming you for the current situation,
>> nor is it your responsibility to go fix vt/fbcon/fbdev driver stack
>> inversion. I'm just trying to bring some awareness of the larger scope,
>> so that collectively we take action and resolve the underlying problems.
>
> Yeah I guess I should tune down my NACK to a Grumpy-if-merged-by too.
> We have a lot of nonoptimal solutions at hand here :(

So where does that leave us with this fix? Should we wait for someone
to come along and do all the rework? Imre said he'd be willing to do
it, but still feels this fix makes sense.

Or we could just abandon the fb layer altogether (my preference). In
that case fixing this is fine, since we'll be able to ignore it for
configs that switch over to using !fbdev and kmscon.

Thanks,
Jesse



\
 
 \ /
  Last update: 2015-03-26 21:41    [W:1.760 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site