[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 at 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.