All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: arjanv@redhat.com,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: The Serial Layer
Date: Thu, 09 Sep 2004 17:28:46 +0100	[thread overview]
Message-ID: <1094747324.14623.49.camel@localhost.localdomain> (raw)
In-Reply-To: <20040909125705.GA5658@thunk.org>

On Iau, 2004-09-09 at 13:57, Theodore Ts'o wrote:
> Calling ldisc.receive_buf directly() should be OK as long as you're
> not in an interrupt handler.  (For example the comtrol driver polls in
> a timer bottom-half, so it's OK to call ldisc.receive_buf).
> Unfortunately, some drivers don't quite follow the rules.

If the driver calls ldisc->receive_buf it means it bypasses the
TTY_DONT_FLIP locking used by the n_tty driver. Am I missing something
here.

> The hangup handling needs to be completely redone, so that we don't
> force serial drivers to do a completely shutdown of the port in an
> interrupt context.  If the drivers are careful, it can be safe, but
> it's too hard to handle hangup correctly.  

Most of that I think comes out in the wash with the ldisc locking. 
Once the driver uses tty_ldisc_ref() it'll get NULL back in the case
where the hangup raced the driver. I'm also no longer dropping back
to N_TTY in the hangup path. I couldn't see any reason this was
neccessary since the release will clean it up anyway ?

Alan


  reply	other threads:[~2004-09-09 17:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-07 18:49 The Serial Layer Alan Cox
2004-09-07 20:06 ` Arjan van de Ven
2004-09-07 19:14   ` Alan Cox
2004-09-09 12:57     ` Theodore Ts'o
2004-09-09 16:28       ` Alan Cox [this message]
2004-09-10 14:32         ` Theodore Ts'o
2004-09-10 15:21           ` Alan Cox
2004-09-07 20:16 ` Russell King
2004-09-12  3:01 ` David Eger
2004-09-12 15:25   ` Alan Cox

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=1094747324.14623.49.camel@localhost.localdomain \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=arjanv@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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.