[Devel] [RFC rh7 v5] ve/tty: vt -- Implement per VE support for console and terminals

[Cyrill Gorcunov]

On 08/27/2015 07:11 PM, Vladimir Davydov wrote:
> 
> Hmm, checkpatch still has max_line_length set to 80. Could you please
> share a link to this agreement?

It was long ago, a few maintainers said about own preference
(Ingo and Andrew iirc) if I manage to find it will send you
a link.

>> fine. Wonder, do you really still sit on 80 chars terminal?
> 
> I use a 12" laptop. With the window vertically split into two panes, I
> have only ~80 characters per each pane.

I see. Fine then, I've already fixed these lines. Hope you won't
switch to some smaller laptop ;-)

>>> May be, we'd better move our ->count tweaking to the generic path, i.e.
>>> tty_release, similarly to pty? We could distinguish vtty from pty by
>>> checking TTY_EXTRA_REF. What do you think?
>>
>> you know, i really don't wanna put our code into generic one, its gonna
>> be hard to support. maybe we should lock the peer manually inside
> 
> Yes, you're right :-(
> 
> OTOH, this would reveal potential problems on build stage, while playing
> with locks can end up with a dead lock after rebase :-/
> 
>> our close routine, so in this way we would have to take own lock, then
>> take peer lock under it, which would protect from abba deadlock. Hm?
>>
>> vtty_close
>> 	spin_lock(&map->close_lock);
>> 	tty_lock(tty->link);
>> 	...
>> 	tty_unlock(tty->link);
>> 	spin_unlock(&map->close_lock);
>>
>> and instead of spinlock I would use mutex here. Won't this work?
> 
> Hmm, ->close is called under tty_lock(tty). That means we can't call
> tty_lock(tty->link) here, neither can we acquire tty_mutex. OTOH, hand
> if we pull patches bringing in tty_lock_slave, this should work. Will it
> be difficult to pull them?

Shouldn't be that hard. Gimme some time (fetch patches is not hard,
but I need to test intensively this construction first).

-- 
    Cyrill