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

[-- Attachment #1: Type: text/plain, Size: 4725 bytes --]

On Thu, 3 Nov 2022, Greg KH wrote:

> 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.

As you can see, the old way is sooo confusing :-). I'll admit I stumbled 
myself with this same default thing first. It's even more confusing than 
the other places.

This check is true when flag bytes are present / required to be present:
	(~flags & TTYB_NORMAL)
It's very very confusing way to check such condition due to layered 
reverse logic.

With old code, the per character flag bytes won't be there in the buffer 
if TTYB_NORMAL is present. Thus, the old default of 0 means 
__tty_buffer_request_room will allocate room for those flag bytes.

If you think about it carefully, the old code passed 0. Therefore, ~0 & 
TTYB_NORMAL is going to be true. After my change true is passed and true 
matches to the original code.

So the logic was not inverted. I just cleared those layered reverse logic 
traps the original had which makes my patch look it's inverting things.

I really appreciate you took your time to find out this little detail
from it! This is far from a simple change because of how trappy the old
way of doing things is.

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

Do you mean you want me to add a comment there? I don't see any 
pre-existing comments that you could be pointing me to.


Should I resubmit it since you probably dropped the patch?


While doing this cleanup, I realized there would likely be room for 
some improvements which would avoid allocing a new tty_buffer. I'll 
probably look into those at some point.


-- 
 i.

  reply	other threads:[~2022-11-03 10:11 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 ` [PATCH v2 1/2] tty: Convert tty_buffer flags to bool Greg KH
2022-11-03 10:11   ` Ilpo Järvinen [this message]
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=b9162bab-41aa-e24c-825-ec1a974b65e6@linux.intel.com \
    --to=ilpo.jarvinen@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --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.