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

Groups > linux.kernel > #1560152 > unrolled thread

[PATCH v2 2/9] tty_port: allow a port to be opened with a tty that has no file handle

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 2/9] tty_port: allow a port to be opened with a tty that has no file handle Rob Herring <robh@kernel.org> - 2017-01-17 00:00 +0100
    Re: [PATCH v2 2/9] tty_port: allow a port to be opened with a tty  that has no file handle One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2017-01-17 16:00 +0100
    Re: [PATCH v2 2/9] tty_port: allow a port to be opened with a tty  that has no file handle Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-19 14:40 +0100
      Re: [PATCH v2 2/9] tty_port: allow a port to be opened with a tty  that has no file handle Rob Herring <robh@kernel.org> - 2017-01-19 16:10 +0100
        Re: [PATCH v2 2/9] tty_port: allow a port to be opened with a tty  that has no file handle Rob Herring <robh@kernel.org> - 2017-01-19 16:40 +0100

#1560152 — [PATCH v2 2/9] tty_port: allow a port to be opened with a tty that has no file handle

From: Alan Cox <alan@linux.intel.com>

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).

Alan
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-By: Sebastian Reichel <sre@kernel.org>
---
Alan, Need your SoB here.

v2:
- no change

 drivers/tty/tty_io.c   | 2 +-
 drivers/tty/tty_port.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 4790c0fb5a45..a1fd3f7d487a 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -855,7 +855,7 @@ static void tty_vhangup_session(struct tty_struct *tty)

 int tty_hung_up_p(struct file *filp)
 {
-	return (filp->f_op == &hung_up_tty_fops);
+	return (filp && filp->f_op == &hung_up_tty_fops);
 }

 EXPORT_SYMBOL(tty_hung_up_p);
diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index c3f9d93ba227..606d9e5bf28f 100644
--- a/drivers/tty/tty_port.c
+++ b/drivers/tty/tty_port.c
@@ -335,7 +335,7 @@ EXPORT_SYMBOL(tty_port_lower_dtr_rts);
  *	tty_port_block_til_ready	-	Waiting logic for tty open
  *	@port: the tty port being opened
  *	@tty: the tty device being bound
- *	@filp: the file pointer of the opener
+ *	@filp: the file pointer of the opener or NULL
  *
  *	Implement the core POSIX/SuS tty behaviour when opening a tty device.
  *	Handles:
@@ -369,7 +369,7 @@ int tty_port_block_til_ready(struct tty_port *port,
 		tty_port_set_active(port, 1);
 		return 0;
 	}
-	if (filp->f_flags & O_NONBLOCK) {
+	if (filp == NULL || (filp->f_flags & O_NONBLOCK)) {
 		/* Indicate we are open */
 		if (C_BAUD(tty))
 			tty_port_raise_dtr_rts(port);
--
2.10.1

[toc] | [next] | [standalone]

#1560675 — Re: [PATCH v2 2/9] tty_port: allow a port to be opened with a tty that has no file handle

On Mon, 16 Jan 2017 16:54:29 -0600
Rob Herring <robh@kernel.org> wrote:

> From: Alan Cox <alan@linux.intel.com>
> 
> 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).
> 
> Alan
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Reviewed-By: Sebastian Reichel <sre@kernel.org>
> ---
> Alan, Need your SoB here.

Signed-off-by: Alan Cox <alan@linux.intel.com>

Alan

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

#1562710 — Re: [PATCH v2 2/9] tty_port: allow a port to be opened with a tty that has no file handle

On Mon, Jan 16, 2017 at 04:54:29PM -0600, Rob Herring wrote:
> From: Alan Cox <alan@linux.intel.com>
> 
> 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).
> 
> Alan
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Reviewed-By: Sebastian Reichel <sre@kernel.org>
> ---
> Alan, Need your SoB here.

Rob, as this patch is flowing through you, I need your signed-off-by as
well if I am to take it.

thanks,

greg k-h

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

#1562811 — Re: [PATCH v2 2/9] tty_port: allow a port to be opened with a tty that has no file handle

On Thu, Jan 19, 2017 at 7:37 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Mon, Jan 16, 2017 at 04:54:29PM -0600, Rob Herring wrote:
>> From: Alan Cox <alan@linux.intel.com>
>>
>> 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).
>>
>> Alan
>> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> Reviewed-By: Sebastian Reichel <sre@kernel.org>
>> ---
>> Alan, Need your SoB here.
>
> Rob, as this patch is flowing through you, I need your signed-off-by as
> well if I am to take it.

Right. I've added both for the next version.

Rob

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

#1562831 — Re: [PATCH v2 2/9] tty_port: allow a port to be opened with a tty that has no file handle

On Thu, Jan 19, 2017 at 9:05 AM, Rob Herring <robh@kernel.org> wrote:
> On Thu, Jan 19, 2017 at 7:37 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
>> On Mon, Jan 16, 2017 at 04:54:29PM -0600, Rob Herring wrote:
>>> From: Alan Cox <alan@linux.intel.com>
>>>
>>> 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).
>>>
>>> Alan
>>> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>>> Reviewed-By: Sebastian Reichel <sre@kernel.org>
>>> ---
>>> Alan, Need your SoB here.
>>
>> Rob, as this patch is flowing through you, I need your signed-off-by as
>> well if I am to take it.
>
> Right. I've added both for the next version.

Oh, I see you applied the 1st patch. Thanks. If you want to apply this
one now here's my S-o-B:

Signed-off-by: Rob Herring <robh@kernel.org>

Patches 3 and 4 can be applied too.

For patch 5, I'd really like someone with more tty knowledge to comment on.

Rob

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web