From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Richard Weinberger <richard@nod.at>, Jiri Slaby <jslaby@suse.cz>,
linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org,
Jiri Slaby <jirislaby@gmail.com>
Subject: Re: TTY: tty_port questions
Date: Sun, 25 Mar 2012 22:06:10 +0100 [thread overview]
Message-ID: <20120325220610.49063ad7@ultron> (raw)
In-Reply-To: <20120325183114.GM6589@ZenIV.linux.org.uk>
On Sun, 25 Mar 2012 19:31:14 +0100
Al Viro <viro@ZenIV.linux.org.uk> wrote:
> How is tty_port supposed to work wrt hotplug? I.e. are those guys (OK,
> the structures they are embedded into) supposed to live as long as
> tty_driver lives? AFAICS, for serial we have an extra layer atop of
> those guys (uart_port) and that's where removals seem to act, but there
> seems to be more to it...
Serial had pre-exising gunge not all of which has been cleaned, just as
it still has its own buffers that want to be using kfifo.
Best examples are probably USB serial and neatest may well be the sdio
serial card driver.
> Suppose we handle uml reconfig requests as port removal + port addition;
> what's needed to make sure that port is out of use and we can play with
> it without stepping on anyone's toes? Something along the lines of what
> uart_remove_one_port() is doing? I.e. tty_unregister_device() + tty_vhangup()?
> But serial_core seems to be open-coding tty_port_open() for some reason
> and _there_ we have port->count updates under port->mutex, so the
> situation might be different...
If you are creating/removing physical ports (or fake physical ports) you
probably need to be refcounting them too.
Alan
next prev parent reply other threads:[~2012-03-25 21:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-10 22:26 TTY: tty_port questions Richard Weinberger
2012-03-10 22:51 ` Jiri Slaby
2012-03-10 23:21 ` Richard Weinberger
2012-03-11 11:01 ` Richard Weinberger
2012-03-12 10:26 ` Richard Weinberger
2012-03-12 10:53 ` Alan Cox
2012-03-12 11:15 ` Richard Weinberger
2012-03-12 11:48 ` Alan Cox
2012-03-24 23:20 ` Al Viro
2012-03-25 14:51 ` Alan Cox
2012-03-25 15:14 ` Richard Weinberger
2012-03-25 17:20 ` Al Viro
2012-03-25 21:09 ` Alan Cox
2012-03-25 18:31 ` Al Viro
2012-03-25 21:06 ` Alan Cox [this message]
2012-03-25 22:33 ` Al Viro
2012-03-28 11:06 ` 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=20120325220610.49063ad7@ultron \
--to=alan@lxorguk.ukuu.org.uk \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@gmail.com \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=richard@nod.at \
--cc=viro@ZenIV.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox