Directly accessing serial ports from drivers w/o TTYs ?

Directly accessing serial ports from drivers w/o TTYs ?

[Enrico Weigelt, metux IT consult]

Hi folks,


is there already a way for accessing serial ports from drivers,
w/o having to go through the TTY subsystem ?

Serdev seems provide a connection between arbitrary TTYs to device
drivers. But this implies always having a TTY for each UART (even if
it's never used outside the kernel).

Is there any way for accessing uarts more directly ?


--mtx

--
Enrico, Sohn von Wilfried, a.d.F. Weigelt,
metux IT consulting
+49-151-27565287

Re: Directly accessing serial ports from drivers w/o TTYs ?

[Alan Cox]

On Mon, 26 Jun 2017 00:43:12 +0200
"Enrico Weigelt, metux IT consult" <enrico.weigelt@gr13.net> wrote:

> Hi folks,
> 
> 
> is there already a way for accessing serial ports from drivers,
> w/o having to go through the TTY subsystem ?
> 
> Serdev seems provide a connection between arbitrary TTYs to device
> drivers. But this implies always having a TTY for each UART (even if
> it's never used outside the kernel).
> 
> Is there any way for accessing uarts more directly ?

You can write your own driver for the physical hardware and claim it in
your driver. Shouldn't normally be needed except for bizarre cases when a
serial link is used for something very non tty like (eg as GPIO lines).

Otherwise all the low level tty device locking, queues and interfaces
assume there is a tty_struct attached to it, so yes you need a tty
struct.

Why do you need to do otherwise ?

Alan

Re: Directly accessing serial ports from drivers w/o TTYs ?

[Enrico Weigelt, metux IT consult]

On 26.06.2017 14:51, Alan Cox wrote:

Hi,

> You can write your own driver for the physical hardware and claim it in
> your driver. Shouldn't normally be needed except for bizarre cases when a
> serial link is used for something very non tty like (eg as GPIO lines).

In my case, it's not really a serial link, but an backplane w/ FIFOs, 
which looks like a serial ports to the host (AFAIK, historically coming
from older systems which actually had various serial controllers, eg.
rs232, rs485/mvb, etc). The backplane seems to simulate the lower
layers of an mvb network.

> Otherwise all the low level tty device locking, queues and interfaces
> assume there is a tty_struct attached to it, so yes you need a tty
> struct.

I was thinking about something that looks like serdev from consumer
side, but instead directly works on struct uart_port, w/o actually
allocating a tty (and also the funny things like signals, etc).

> Why do you need to do otherwise ?

Maybe it could offer better performance ?


--mtx

Re: Directly accessing serial ports from drivers w/o TTYs ?

[Alan Cox]

> I was thinking about something that looks like serdev from consumer
> side, but instead directly works on struct uart_port, w/o actually
> allocating a tty (and also the funny things like signals, etc).

uart_port is only a subset of tty devices and also relies upon tty for
some of the locking and other behaviour.

> > Why do you need to do otherwise ?  
> 
> Maybe it could offer better performance ?

Unless you have very tight latency requirements I would be surprised if
you could do that much better even on a slow machine. If you don't need
tty semantics then you can probably beat it hands down by writing your
own custom driver for the hardware that doesn't pretend to be a tty in
the first place.

The cost in the tty stack is pretty much all the Unix tty API and POSIX
guarantees.

Alan