All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: linux-serial@vger.kernel.org, Jiri Slaby <jirislaby@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] tty: Convert tty_buffer flags to bool
Date: Thu, 3 Nov 2022 03:55:42 +0100	[thread overview]
Message-ID: <Y2Mtricfx/HxiEHc@kroah.com> (raw)
In-Reply-To: <20221019105504.16800-1-ilpo.jarvinen@linux.intel.com>

On Wed, Oct 19, 2022 at 01:55:03PM +0300, Ilpo Järvinen wrote:
> The struct tty_buffer has flags which is only used for storing TTYB_NORMAL.
> There is also a few quite confusing operations for checking the presense
> of TTYB_NORMAL. Simplify things by converting flags to bool.
> 
> Despite the name remaining the same, the meaning of "flags" is altered
> slightly by this change. Previously it referred to flags of the buffer
> (only TTYB_NORMAL being used as a flag). After this change, flags tell
> whether the buffer contains/should be allocated with flags array along
> with character data array. It is much more suitable name that
> TTYB_NORMAL was for this purpose, thus the name remains.
> 
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> ---
> 
> v2:
> - Make it more obvious why flags is not renamed (both in kerneldoc
>   comment and commit message).
> 
>  drivers/tty/tty_buffer.c   | 28 ++++++++++++++--------------
>  include/linux/tty_buffer.h |  5 +----
>  include/linux/tty_flip.h   |  4 ++--
>  3 files changed, 17 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
> index 5e287dedce01..b408d830fcbc 100644
> --- a/drivers/tty/tty_buffer.c
> +++ b/drivers/tty/tty_buffer.c
> @@ -107,7 +107,7 @@ static void tty_buffer_reset(struct tty_buffer *p, size_t size)
>  	p->commit = 0;
>  	p->lookahead = 0;
>  	p->read = 0;
> -	p->flags = 0;
> +	p->flags = true;
>  }
>  
>  /**
> @@ -249,7 +249,7 @@ void tty_buffer_flush(struct tty_struct *tty, struct tty_ldisc *ld)
>   * __tty_buffer_request_room	-	grow tty buffer if needed
>   * @port: tty port
>   * @size: size desired
> - * @flags: buffer flags if new buffer allocated (default = 0)
> + * @flags: buffer has to store flags along character data
>   *
>   * Make at least @size bytes of linear space available for the tty buffer.
>   *
> @@ -260,19 +260,19 @@ void tty_buffer_flush(struct tty_struct *tty, struct tty_ldisc *ld)
>   * Returns: the size we managed to find.
>   */
>  static int __tty_buffer_request_room(struct tty_port *port, size_t size,
> -				     int flags)
> +				     bool flags)
>  {
>  	struct tty_bufhead *buf = &port->buf;
>  	struct tty_buffer *b, *n;
>  	int left, change;
>  
>  	b = buf->tail;
> -	if (b->flags & TTYB_NORMAL)
> +	if (!b->flags)
>  		left = 2 * b->size - b->used;
>  	else
>  		left = b->size - b->used;
>  
> -	change = (b->flags & TTYB_NORMAL) && (~flags & TTYB_NORMAL);
> +	change = !b->flags && flags;
>  	if (change || left < size) {
>  		/* This is the slow path - looking for new buffers to use */
>  		n = tty_buffer_alloc(port, size);
> @@ -300,7 +300,7 @@ static int __tty_buffer_request_room(struct tty_port *port, size_t size,
>  
>  int tty_buffer_request_room(struct tty_port *port, size_t size)
>  {
> -	return __tty_buffer_request_room(port, size, 0);
> +	return __tty_buffer_request_room(port, size, true);

Did this logic just get inverted?

Maybe it's the jet-lag, but this feels like it's not correct anymore.

Maybe a commet up above where you calculate "left" would make more sense
as to what is going on?

thanks,

greg k-h

  parent reply	other threads:[~2022-11-03  2:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-19 10:55 [PATCH v2 1/2] tty: Convert tty_buffer flags to bool Ilpo Järvinen
2022-10-19 10:55 ` [PATCH v2 2/2] tty: Cleanup tty buffer align mask Ilpo Järvinen
2022-11-03  2:55 ` Greg KH [this message]
2022-11-03 10:11   ` [PATCH v2 1/2] tty: Convert tty_buffer flags to bool Ilpo Järvinen
2022-11-09 12:02     ` Greg KH

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=Y2Mtricfx/HxiEHc@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=jirislaby@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@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.