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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070813205523.GA9412@csclub.uwaterloo.ca>
Date:	Mon, 13 Aug 2007 16:55:23 -0400
From:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:	Brad Campbell <brad@...p.net.au>
Cc:	lkml <linux-kernel@...r.kernel.org>
Subject: Re: Advice on a userspace tty serial driver

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
-
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/