Re: [PATCH 1/5] staging: speakup: enable access to tty device

Re: [PATCH 1/5] staging: speakup: enable access to tty device

[Okash Khawaja]

enable acess to tty device from kernel module

Re: [PATCH 1/5] staging: speakup: enable access to tty device

[Samuel Thibault]

Hello,

Okash Khawaja, on Wed 08 Feb 2017 22:46:32 +0000, wrote:
> enable acess to tty device from kernel module

Are you sending them by hand?  At the very least, you need to attach
patches with text/plain type, otherwise it's a real pain to review.  But
actually quilt has a "mail" command, which you can use to prepare the
mails to be sent.  And BTW, better use --reply-to to make the various
mails part of the same mail thread.

Samuel

Re: [PATCH 1/5] staging: speakup: enable access to tty device

[Samuel Thibault]

Okash Khawaja, on Wed 08 Feb 2017 22:46:32 +0000, wrote:
> enable acess to tty device from kernel module

You need much more explanations, and also this is based on a patch from
Alan Cox
(http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1215095.html),
so you should integrate the explanations, something like:

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

You'll need to have Alan Cox in Cc when actually submitting the patch,
so he gets to comment on it.  You'll then have to add your Signed-off-By
along his own, see linux/Documentation/SubmittingPatches for the
details.

Samuel

Re: [PATCH 1/5] staging: speakup: enable access to tty device

[Okash Khawaja]

On Wed, Feb 8, 2017 at 10:52 PM, Samuel Thibault
<samuel.thibault@ens-lyon.org> wrote:
> Hello,
>
> Okash Khawaja, on Wed 08 Feb 2017 22:46:32 +0000, wrote:
>> enable acess to tty device from kernel module
>
> Are you sending them by hand?  At the very least, you need to attach
> patches with text/plain type, otherwise it's a real pain to review.  But
> actually quilt has a "mail" command, which you can use to prepare the
> mails to be sent.  And BTW, better use --reply-to to make the various
> mails part of the same mail thread.
>
> Samuel

Of course. I thought the mail client would do both - reply-to and
text/plain attachments. I'll send them using quilt. Please ignore the
rest of patches.

Re: [PATCH 1/5] staging: speakup: enable access to tty device

[Okash Khawaja]

On Wed, Feb 8, 2017 at 10:59 PM, Samuel Thibault
<samuel.thibault@ens-lyon.org> wrote:
> Okash Khawaja, on Wed 08 Feb 2017 22:46:32 +0000, wrote:
>> enable acess to tty device from kernel module
>
> You need much more explanations, and also this is based on a patch from
> Alan Cox
> (http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1215095.html),
> so you should integrate the explanations, something like:
>
> “
> 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).
> ”
>
> You'll need to have Alan Cox in Cc when actually submitting the patch,
> so he gets to comment on it.  You'll then have to add your Signed-off-By
> along his own, see linux/Documentation/SubmittingPatches for the
> details.
>
> Samuel

Okay, wasn't best placed to put in details for this this one so the
above really helps. Will follow this with better formatted patch set.