Advice on a userspace tty serial driver

Advice on a userspace tty serial driver

[Brad Campbell]

G'day all,

I'm building a bit of hardware. It's basically a serial multiplexer that communicates to the PC 
using a single usb-serial port. It has the ability to run between 2 and 8 standard async ports over 
this single interface.

I'd rather not write a kernel driverif possible as I figure this would be a perfect application for 
a userspace daemon to do the control and mux/demux. I'd prefer to present standard serial style 
devices (/dev/ttySxx) to userspace giving me the ability to run unmodified software to talk to the 
multiplexed ports.

I think tty/pty pairs looks roughly what I'm after, but will they allow me to use standard IOCTLS 
for conveying baud rate and other standard serial parameters to the daemon?

I've spotted several userspace serial driver projects in the last 7 or so years, but I can't seem to 
find any that made it into the kernel.

Am I on the right track with tty/pty or is there a better way?

Regards,
Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: Advice on a userspace tty serial driver

[Lennart Sorensen]

On Fri, Aug 10, 2007 at 04:28:19PM +0400, Brad Campbell wrote:
> I'm building a bit of hardware. It's basically a serial multiplexer that 
> communicates to the PC using a single usb-serial port. It has the ability 
> to run between 2 and 8 standard async ports over this single interface.
> 
> I'd rather not write a kernel driverif possible as I figure this would be a 
> perfect application for a userspace daemon to do the control and mux/demux. 
> I'd prefer to present standard serial style devices (/dev/ttySxx) to 
> userspace giving me the ability to run unmodified software to talk to the 
> multiplexed ports.
> 
> I think tty/pty pairs looks roughly what I'm after, but will they allow me 
> to use standard IOCTLS for conveying baud rate and other standard serial 
> parameters to the daemon?
> 
> I've spotted several userspace serial driver projects in the last 7 or so 
> years, but I can't seem to find any that made it into the kernel.
> 
> Am I on the right track with tty/pty or is there a better way?

I don't think you can do any serial specific stuff, like parity and stop
bits and the like across a pty.  You might have to actually write a
serial driver to present the devices and handle the ioctls, even if you
have a user space process handle the mux/demux between the real serial
port and the fake ports.

I am curious how you are going to pass the data to the external device,
and indicate which port the data should go through.  What will you do
when there is too much data being sent for the real serial port to
handle?  I guess if you had a single high speed port, that would be a
start.

--
Len Sorensen

Re: Advice on a userspace tty serial driver

[Alan Cox]

> I don't think you can do any serial specific stuff, like parity and stop
> bits and the like across a pty.  You might have to actually write a

They will let you do that. Any options you set one side become visible
the other.

Alan

Re: Advice on a userspace tty serial driver

[Arnaldo Carvalho de Melo]

Em Mon, Aug 13, 2007 at 04:55:23PM -0400, Lennart Sorensen escreveu:
> On Fri, Aug 10, 2007 at 04:28:19PM +0400, Brad Campbell wrote:
> > I'm building a bit of hardware. It's basically a serial multiplexer that 
> > communicates to the PC using a single usb-serial port. It has the ability 
> > to run between 2 and 8 standard async ports over this single interface.
> > 
> > I'd rather not write a kernel driverif possible as I figure this would be a 
> > perfect application for a userspace daemon to do the control and mux/demux. 
> > I'd prefer to present standard serial style devices (/dev/ttySxx) to 
> > userspace giving me the ability to run unmodified software to talk to the 
> > multiplexed ports.
> > 
> > I think tty/pty pairs looks roughly what I'm after, but will they allow me 
> > to use standard IOCTLS for conveying baud rate and other standard serial 
> > parameters to the daemon?
> > 
> > I've spotted several userspace serial driver projects in the last 7 or so 
> > years, but I can't seem to find any that made it into the kernel.
> > 
> > Am I on the right track with tty/pty or is there a better way?
> 
> I don't think you can do any serial specific stuff, like parity and stop
> bits and the like across a pty.  You might have to actually write a

Well, the mux could check this next time select/poll indicates there is
something to read from the pty and use the GSM0710 modem bits setting
packet type to communicate that to the hardware that has the async
ports.

This is just handwaving tho, haven't checked if TCSETS works well on a
pty and if afterwards a TCGETS will retrieve the changed values. Check
if that is the case and try to find a way to avoid doing a TCGETS for
every read from the pty, perhaps with a flag that starts at zero and at
first read you set it to one, then after you detect that the pty was
closed you set it back to zero.

> serial driver to present the devices and handle the ioctls, even if you
> have a user space process handle the mux/demux between the real serial
> port and the fake ports.
> 
> I am curious how you are going to pass the data to the external device,
> and indicate which port the data should go through.  What will you do

Look at GSM 07/10. I implemented a userland multiplexer for a customer,
that decided to keep it closed, but I think that Harald Welte has
written an open source implementation in the open moko project, haven't
checked this tho.

No need to implement it all on the hardware with the async ports side,
just the type 0 (if my memory serves me 8) will be enough for what you
want.

> when there is too much data being sent for the real serial port to
> handle?  I guess if you had a single high speed port, that would be a
> start.

Well, just use a select look on the pty and the real serial device and
mux/demux using GSM0710, apps will be throttled by the pty code, etc.

- Arnaldo