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
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
