linux-kernel - Re: [PATCH 16/16] tty: drop tty_flip_buffer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <01079c75-2d2f-fe57-db0e-6aadf9963846@kernel.org>
Date:   Thu, 18 Nov 2021 08:54:05 +0100
From:   Jiri Slaby <jirislaby@...nel.org>
To:     Johan Hovold <johan@...nel.org>, gregkh@...uxfoundation.org
Cc:     linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 16/16] tty: drop tty_flip_buffer_push

Friendly ping Johan, Greg: any opinions on the tty_schedule_flip vs 
tty_flip_buffer_push case -- which one should I keep?

I would like to move forward with these as I have a lot kernel-doc 
writings pending and depending on this patch (be it "drop 
tty_flip_buffer_push" or "drop tty_schedule_flip").

Thanks.

On 22. 09. 21, 8:57, Jiri Slaby wrote:
> On 16. 09. 21, 12:03, Johan Hovold wrote:
>> On Tue, Sep 14, 2021 at 11:14:15AM +0200, Jiri Slaby wrote:
>>> Since commit a9c3f68f3cd8d (tty: Fix low_latency BUG) in 2014,
>>> tty_flip_buffer_push() is only a wrapper to tty_schedule_flip(). All
>>> users were converted, so remove tty_flip_buffer_push() completely.
>>
>> Did you consider inlining tty_flip_buffer_push() or unexporting
>> tty_schedule_flip() instead?
> 
> Yes -- I see no reason for two functions doing the very same thing. It's 
> only confusing.
> 
>> The name tty_flip_buffer_push() is arguable more descriptive since the
>> work may already be running and is also less tied to the implementation.
>>
>> The ratio of drivers using tty_flip_buffer_push() over
>> tty_schedule_flip() is also something like 186 to 15 so that would
>> amount to a lot less churn too.
> 
> OK, I can do either way. I chose this path as tty_schedule_flip was a 
> wrapper to tty_flip_buffer_push. In any case, I wouldn't take the number 
> of changed drivers as a measure. But if it makes more sense for people 
> regarding the naming, I will "flip" the two flips.



-- 
js
suse labs