tty loop-back device

tty loop-back device

[Matwey V. Kornilov]

Hi,

Not sure whether here is the right place to ask. Do the kernel already 
has (or, would it be great to have) the tty loop-back support? At least 
I've not found something appropriate. I mean, imagine kind of /dev/tty 
device, supporting read/write and termios interface and transferring 
your read/write/ioctl calls to another user-space application listening, 
for instance, /dev/tty_loopback_master. Like a named pipe device.

The idea behind that is there are a lot of devices like RS232/485 
network ports, for instance:

http://www.moxa.com/product/nport_5110.htm
http://www.lantronix.com/device-networking/embedded-device-servers/xport.html
http://gridconnect.com/rs485-ethernet.html

They are just network devices which transfer kind of telnet protocol 
into their-own UARTs.

At the other hand, you have user-space application that wants to operate 
with tty serial device. And since there is standard termios interface in 
kernel, the user-space application don't care whether the serial port is 
real UART, usb-serial, AMBA, etc. We can transparently swap our 
hardware. That is not always the case when you use networked serial and 
have to communicate over IP.

Moxa NPort kernel driver is implemented in the way I am talking about 
(if I understand the code correctly). There is daemon application 
communicating with the IP network and putting data received back to the 
kernel.

Re: tty loop-back device

[Grant Edwards]

On 2013-09-28, Matwey V. Kornilov <matwey.kornilov@gmail.com> wrote:

> Not sure whether here is the right place to ask. Do the kernel already 
> has (or, would it be great to have) the tty loop-back support? At least 
> I've not found something appropriate. I mean, imagine kind of /dev/tty 
> device, supporting read/write and termios interface and transferring 
> your read/write/ioctl calls to another user-space application listening, 
> for instance, /dev/tty_loopback_master. Like a named pipe device.

What you're talking about is pretty much the existing pty device.

Unfortunately, Linux pty's only support a subset of the serial port
API, so they can't be used for applications like network-connected
serial ports.  So people like me have to write kernel-mode drivers for
such devices.

I've suggested extending the Linux pty so that it _does_ support the
rest of the serial port API.  I even offered to work on it if the
results would likely be accepted into the kernel tree, but my
questions/offers have never gotten any response.

-- 
Grant

Re: tty loop-back device

[Greg KH]

On Sat, Sep 28, 2013 at 04:03:20PM +0000, Grant Edwards wrote:
> 
> I've suggested extending the Linux pty so that it _does_ support the
> rest of the serial port API.  I even offered to work on it if the
> results would likely be accepted into the kernel tree, but my
> questions/offers have never gotten any response.

I can't ever say that I'll "guarantee" acceptance of a patch into the
tree before I see what it looks like.  But if something like this is
reasonable, and doesn't break existing users, I don't see why it
wouldn't make sense to have merged.

thanks,

greg k-h

Re: tty loop-back device

[Matwey V. Kornilov]

28.09.2013 20:03, Grant Edwards пишет:
> What you're talking about is pretty much the existing pty device.
>
> Unfortunately, Linux pty's only support a subset of the serial port
> API, so they can't be used for applications like network-connected
> serial ports.  So people like me have to write kernel-mode drivers for
> such devices.

Yep, pty_set_termios looks like a mock or dummy, when it is critical 
part to applications like network serial port devices. One needs to set 
baudrate, parity, etc.

> I've suggested extending the Linux pty so that it _does_ support the
> rest of the serial port API.  I even offered to work on it if the
> results would likely be accepted into the kernel tree, but my
> questions/offers have never gotten any response.

It seems that BSD and Unix98 pty's may coexist in pty.c. So, there is a 
chance that it is possible to add support of Extended pty not breaking 
existing things. One need to be a brave to change something in pty.c, It 
is quite critical part.

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: tty loop-back device

[Matwey V. Kornilov]

28.09.2013 21:21, Matwey V. Kornilov пишет:
> It seems that BSD and Unix98 pty's may coexist in pty.c. So, there is a
> chance that it is possible to add support of Extended pty not breaking
> existing things. One need to be a brave to change something in pty.c, It
> is quite critical part.

It seems that we need new line discipline to allow async notification of 
master tty when the client changes tty->termios. poll() has to be 
reimplemented to generate POLLPRI, when tty->termios handling required 
on the master side, then master may use special ioctl to read 
tty->termios requested.


--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: tty loop-back device

[Grant Edwards]

On 2013-09-28, Matwey V. Kornilov <matwey.kornilov@gmail.com> wrote:
> 28.09.2013 21:21, Matwey V. Kornilov ?????:
>> It seems that BSD and Unix98 pty's may coexist in pty.c. So, there is a
>> chance that it is possible to add support of Extended pty not breaking
>> existing things. One need to be a brave to change something in pty.c, It
>> is quite critical part.
>
> It seems that we need new line discipline to allow async notification of 
> master tty when the client changes tty->termios. poll() has to be 
> reimplemented to generate POLLPRI, when tty->termios handling required 
> on the master side, then master may use special ioctl to read 
> tty->termios requested.

I was thinking about initially just creating a blocking ioctl() call
that the master can use to wait for either a termios configuration
change or a modem control line change.  I admit that's not as elegent:
it would mean a master would need multiple threads in most cases (one
for data and one for config and modem status).  But, it may be a less
intrusive change [I haven't looked at the poll implementation in any
detail, so perhaps the poll change isn't as bad as I fear.]

Having to use multiple threads in a master sounds ugly at first, but
it's still orders of magnitude easier than implementing a serial
driver in kernel space that uses network I/O to communicate with the
physical UART.

-- 
Grant

Re: tty loop-back device

[Matwey V. Kornilov]

29.09.2013 07:21, Grant Edwards пишет:
> I was thinking about initially just creating a blocking ioctl() call
> that the master can use to wait for either a termios configuration
> change or a modem control line change.  I admit that's not as elegent:
> it would mean a master would need multiple threads in most cases (one
> for data and one for config and modem status).  But, it may be a less
> intrusive change [I haven't looked at the poll implementation in any
> detail, so perhaps the poll change isn't as bad as I fear.]

The simplier way is to use master in 'packet mode' (see TIOCPKT). Then 
we can distinguish stream data from termios notification for every 
master's read. It either starts with '\0' and the following is the data 
to transmit or with control symbol and then master have to use ioctl to 
read new tty->termios.

> Having to use multiple threads in a master sounds ugly at first, but
> it's still orders of magnitude easier than implementing a serial
> driver in kernel space that uses network I/O to communicate with the
> physical UART.

For sure.

We need way more ioctls. Since every new slave pty is enumerated almost 
randomly (depends on how many sessions is opened, opening order, etc), 
we have to mark somehow the pty when the daemon creates it, then udev 
should be able to create appropriate symbolic link for client user-space 
application. Then user-space client may be configured to work with 
/dev/tty/by-name/uniqname for instance.

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: tty loop-back device

[Grant Edwards]

On 2013-09-29, Matwey V. Kornilov <matwey.kornilov@gmail.com> wrote:
> 29.09.2013 07:21, Grant Edwards ?????:
>> I was thinking about initially just creating a blocking ioctl() call
>> that the master can use to wait for either a termios configuration
>> change or a modem control line change.  I admit that's not as elegent:
>> it would mean a master would need multiple threads in most cases (one
>> for data and one for config and modem status).  But, it may be a less
>> intrusive change [I haven't looked at the poll implementation in any
>> detail, so perhaps the poll change isn't as bad as I fear.]
>
> The simplier way is to use master in 'packet mode' (see TIOCPKT). Then 
> we can distinguish stream data from termios notification for every 
> master's read. It either starts with '\0' and the following is the data 
> to transmit or with control symbol and then master have to use ioctl to 
> read new tty->termios.

I can't believe I didn't know about packet mode.  That's exactly what
is needed.  Defining two new bits (e.g. TIOCPKT_TERMIOS, TIOCPKT_MSET)
would pretty much take care of things.  Just a single new bit to
notify of changes to either termios or modem lines would be good
enough.

> We need way more ioctls. Since every new slave pty is enumerated
> almost randomly (depends on how many sessions is opened, opening
> order, etc), we have to mark somehow the pty when the daemon creates
> it, then udev should be able to create appropriate symbolic link for
> client user-space application. Then user-space client may be
> configured to work with /dev/tty/by-name/uniqname for instance.

I've never looked at how pty slave side device nodes get named...

-- 
Grant Edwards               grant.b.edwards        Yow! I just forgot my whole
                                  at               philosophy of life!!!
                              gmail.com