linux-kernel - Re: Advice on a userspace tty serial driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20070813213200.GG20665@ghostprotocols.net>
Date:	Mon, 13 Aug 2007 18:32:00 -0300
From:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
To:	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>
Cc:	Brad Campbell <brad@...p.net.au>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: Advice on a userspace tty serial driver

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/