Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1641943 > unrolled thread

[patch v2 1/6] tty: export tty_open_by_driver

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [patch v2 1/6] tty: export tty_open_by_driver Okash Khawaja <okash.khawaja@gmail.com> - 2017-05-15 20:00 +0200
    Re: [patch v2 1/6] tty: export tty_open_by_driver Christoph Hellwig <hch@infradead.org> - 2017-05-21 08:10 +0200
      Re: [patch v2 1/6] tty: export tty_open_by_driver Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-21 09:50 +0200

#1641943 — [patch v2 1/6] tty: export tty_open_by_driver

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)
 { }

[toc] | [next] | [standalone]

#1646264

On Mon, May 15, 2017 at 06:45:32PM +0100, Okash Khawaja wrote:
> 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:

Any non-staging users?  Please don't add new APIs with proper in-kernel
users (and staging doesn't count for that).

[toc] | [prev] | [next] | [standalone]

#1646278

On Sat, May 20, 2017 at 11:09:02PM -0700, Christoph Hellwig wrote:
> On Mon, May 15, 2017 at 06:45:32PM +0100, Okash Khawaja wrote:
> > 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:
> 
> Any non-staging users?  Please don't add new APIs with proper in-kernel
> users (and staging doesn't count for that).

I'll give the speakup code a pass here, as they are trying to get this
cleaned up properly and moved into the correct location.  It's almost
ready, with this and the serdev interface, it should be pretty close...

thanks,

greg k-h

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web