From: Okash Khawaja <okash.khawaja@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>,
Samuel Thibault <samuel.thibault@ens-lyon.org>,
linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org,
Kirk Reiser <kirk@reisers.ca>,
speakup@linux-speakup.org, alan@linux.intel.com,
Chris Brannon <chris@the-brannons.com>
Subject: Re: [patch 1/7] tty_port: allow a port to be opened with a tty that has no file handle
Date: Mon, 13 Mar 2017 22:38:47 +0000 [thread overview]
Message-ID: <20170313223847.GA337@sanghar> (raw)
In-Reply-To: <20170313221247.GA22823@kroah.com>
On Tue, Mar 14, 2017 at 06:12:47AM +0800, Greg Kroah-Hartman wrote:
> On Mon, Mar 13, 2017 at 10:05:52PM +0000, okash.khawaja@gmail.com wrote:
> > Allow access to TTY device from kernel. This is based on Alan Cox's patch
> > (http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1215095.html),
> > with description quoted below.
> >
> > "tty_port: allow a port to be opened with a tty that has no file handle
> >
> > Let us create tty objects entirely in kernel space.
> >
> > With this a kernel created non file backed tty object could be used to handle
> > data, and set terminal modes. Not all ldiscs can cope with this as N_TTY in
> > particular has to work back to the fs/tty layer.
> >
> > The tty_port code is however otherwise clean of file handles as far as I can
> > tell as is the low level tty port write path used by the ldisc, the
> > configuration low level interfaces and most of the ldiscs.
> >
> > Currently you don't have any exposure to see tty hangups because those are
> > built around the file layer. However a) it's a fixed port so you probably
> > don't care about that b) if you do we can add a callback and c) you almost
> > certainly don't want the userspace tear down/rebuild behaviour anyway.
> >
> > This should however be sufficient if we wanted for example to enumerate all
> > the bluetooth bound fixed ports via ACPI and make them directly available.
> >
> > It doesn't deal with the case of a user opening a port that's also kernel
> > opened and that would need some locking out (so it returned EBUSY if bound
> > to a kernel device of some kind). That needs resolving along with how you
> > "up" or "down" your new bluetooth device, or enumerate it while providing
> > the existing tty API to avoid regressions (and to debug)."
> >
> > Signed-off-by: Okash Khawaja <okash.khawaja@gmail.com>
> >
> > Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
>
> You do know this is already in 4.11-rc1, right? Please rebase your
> patch set on 4.11-rc2 at the least and resend.
Didn't realise that! Will resend
next prev parent reply other threads:[~2017-03-13 22:38 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-13 22:05 [patch 0/7] staging: speakup: introduce tty-based comms okash.khawaja
2017-03-13 22:05 ` [patch 1/7] tty_port: allow a port to be opened with a tty that has no file handle okash.khawaja
2017-03-13 22:12 ` Greg Kroah-Hartman
2017-03-13 22:38 ` Okash Khawaja [this message]
2017-03-14 9:14 ` Dan Carpenter
2017-03-13 22:05 ` [patch 2/7] staging: speakup: spk_serial_out and spk_wait_for_xmitr to take synth arg okash.khawaja
2017-03-13 22:05 ` [patch 3/7] staging: serial: add spk_io_ops struct to spk_synth okash.khawaja
2017-03-13 22:05 ` [patch 4/7] staging: speakup: move spk_stop_serial_interrupt into synth-specific release function okash.khawaja
2017-03-13 22:05 ` [patch 5/7] staging: speakup: move those functions which do outgoing serial comms, into serialio.c okash.khawaja
2017-03-13 22:05 ` [patch 6/7] staging: speakup: add tty-based comms functions okash.khawaja
2017-03-13 22:05 ` [patch 7/7] staging: speakup: migrate acntsa, bns, dummy and txprt to ttyio okash.khawaja
2017-03-13 22:14 ` [patch 0/7] staging: speakup: introduce tty-based comms Greg Kroah-Hartman
2017-03-13 22:26 ` Samuel Thibault
2017-03-13 23:43 ` Greg Kroah-Hartman
2017-03-13 23:49 ` Samuel Thibault
2017-03-14 0:00 ` Samuel Thibault
2017-03-14 0:47 ` Samuel Thibault
2017-03-14 1:18 ` Samuel Thibault
2017-03-15 14:45 ` Rob Herring
2017-03-15 15:03 ` Samuel Thibault
2017-03-22 0:05 ` Samuel Thibault
2017-04-09 16:54 ` Okash Khawaja
2017-03-16 9:26 ` Samuel Thibault
2017-03-14 0:24 ` Samuel Thibault
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=20170313223847.GA337@sanghar \
--to=okash.khawaja@gmail.com \
--cc=alan@linux.intel.com \
--cc=chris@the-brannons.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.com \
--cc=kirk@reisers.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=samuel.thibault@ens-lyon.org \
--cc=speakup@linux-speakup.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).