From: Okash Khawaja <okash.khawaja@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jslaby@suse.com>,
Samuel Thibault <samuel.thibault@ens-lyon.org>,
linux-kernel@vger.kernel.org
Cc: William Hubbs <w.d.hubbs@gmail.com>,
Chris Brannon <chris@the-brannons.com>,
Kirk Reiser <kirk@reisers.ca>,
speakup@linux-speakup.org, devel@driverdev.osuosl.org,
Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
Okash Khawaja <okash.khawaja@gmail.com>
Subject: [patch v2 1/6] tty: export tty_open_by_driver
Date: Mon, 15 May 2017 18:45:32 +0100 [thread overview]
Message-ID: <20170515175611.655323933@gmail.com> (raw)
In-Reply-To: 20170515174531.968330974@gmail.com
[-- Attachment #1: 02_export_tty_open_by_driver --]
[-- Type: text/plain, Size: 3892 bytes --]
This exports tty_open_by_driver so that it can be called from other places inside the kernel. The checks for null file pointer are based on Alan Cox's patch here: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1215095.html. Description below is quoted from it:
"[RFC] 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. Untested proposal to
show why all the ideas around rewriting half the uart stack are not needed.
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)."
The exported funtion is used later in this patch set to gain access to tty_struct.
Signed-off-by: Okash Khawaja <okash.khawaja@gmail.com>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Index: linux-staging/drivers/tty/tty_io.c
===================================================================
--- linux-staging.orig/drivers/tty/tty_io.c
+++ linux-staging/drivers/tty/tty_io.c
@@ -1369,7 +1369,10 @@ static struct tty_struct *tty_driver_loo
struct tty_struct *tty;
if (driver->ops->lookup)
- tty = driver->ops->lookup(driver, file, idx);
+ if (!file)
+ tty = ERR_PTR(-EIO);
+ else
+ tty = driver->ops->lookup(driver, file, idx);
else
tty = driver->ttys[idx];
@@ -2001,7 +2004,7 @@ static struct tty_driver *tty_lookup_dri
struct tty_driver *console_driver = console_device(index);
if (console_driver) {
driver = tty_driver_kref_get(console_driver);
- if (driver) {
+ if (driver && filp) {
/* Don't let /dev/console block */
filp->f_flags |= O_NONBLOCK;
break;
@@ -2034,7 +2037,7 @@ static struct tty_driver *tty_lookup_dri
* - concurrent tty driver removal w/ lookup
* - concurrent tty removal from driver table
*/
-static struct tty_struct *tty_open_by_driver(dev_t device, struct inode *inode,
+struct tty_struct *tty_open_by_driver(dev_t device, struct inode *inode,
struct file *filp)
{
struct tty_struct *tty;
@@ -2079,6 +2082,7 @@ out:
tty_driver_kref_put(driver);
return tty;
}
+EXPORT_SYMBOL(tty_open_by_driver);
/**
* tty_open - open a tty device
Index: linux-staging/include/linux/tty.h
===================================================================
--- linux-staging.orig/include/linux/tty.h
+++ linux-staging/include/linux/tty.h
@@ -401,6 +401,8 @@ extern struct tty_struct *get_current_tt
/* tty_io.c */
extern int __init tty_init(void);
extern const char *tty_name(const struct tty_struct *tty);
+extern struct tty_struct *tty_open_by_driver(dev_t device, struct inode *inode,
+ struct file *filp);
#else
static inline void console_init(void)
{ }
next prev parent reply other threads:[~2017-05-15 17:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-15 17:45 [patch v2 0/6] staging: speakup: migrate synths to use TTY-based comms Okash Khawaja
2017-05-15 17:45 ` Okash Khawaja [this message]
2017-05-21 6:09 ` [patch v2 1/6] tty: export tty_open_by_driver Christoph Hellwig
2017-05-21 7:43 ` Greg Kroah-Hartman
2017-05-15 17:45 ` [patch v2 2/6] staging: speakup: add tty-based comms functions Okash Khawaja
2017-05-15 17:45 ` [patch v2 3/6] staging: speakup: migrate acntsa, bns, dummy and txprt to ttyio Okash Khawaja
2017-05-15 17:45 ` [patch v2 4/6] staging: speakup: add send_xchar, tiocmset and input functionality for tty Okash Khawaja
2017-05-15 17:45 ` [patch v2 5/6] staging: speakup: migrate apollo, ltlk, audptr, decext, dectlk and spkout Okash Khawaja
2017-05-15 17:45 ` [patch v2 6/6] staging: speakup: flush tty buffers and ensure hardware flow control Okash Khawaja
2017-05-16 12:00 ` Greg Kroah-Hartman
2017-05-16 12:19 ` Okash Khawaja
2017-05-16 12:28 ` Greg Kroah-Hartman
2017-05-16 12:51 ` Okash Khawaja
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=20170515175611.655323933@gmail.com \
--to=okash.khawaja@gmail.com \
--cc=chris@the-brannons.com \
--cc=devel@driverdev.osuosl.org \
--cc=gnomes@lxorguk.ukuu.org.uk \
--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 \
--cc=w.d.hubbs@gmail.com \
/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