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
next prev parent 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.