Hello
I am writing a kernel module device driver for a special sort of modem that doesn't use the standard AT command set.
Basically it is a protocol translator, user mode programs such as minicom or ppp will open my device, send their AT commands, and my driver will translate the data both directions. The device attaches to the serial port.
I have written the top half, the interface between the user mode and the driver. My question now is how to open a connection to the serial port that the device is attached to.
My first thought was to use sys_open but that is not exported, because kernel modules don't need access to files.
What is the preferred way in Linux for my module to open the serial port device such as /dev/ttyS1.
Thanks a lot
Kurt H?usler
On Mer, 2003-07-23 at 15:15, Kurt Häusler wrote:
> What is the preferred way in Linux for my module to open the serial port device such as /dev/ttyS1.
Make your driver a line discipline is the normal approach in this case
(ok to be fair putting it all in user space is the normal case). Take a
look at slip.c to see how slip sits above terminal interfaces.
The user space only approach is to use pty/tty pairs as things like
xterm do. This gives you a "terminal/serial" device the other end of
which is your user space program which can do the conversions it wants
then talk to a real serial port
On Wed, Jul 23, 2003 at 03:25:43PM +0100, Alan Cox wrote:
> The user space only approach is to use pty/tty pairs as things like
> xterm do. This gives you a "terminal/serial" device the other end of
> which is your user space program which can do the conversions it wants
> then talk to a real serial port
In this latter approach is there any way for the user space program to
catch the termios ioctls (eg to set baud rate etc) that the
application does on the tty end of the pty/tty pair?
(I believe the answer is no! I got half way through writing a pty/tty
replacement driver which passed the relevant ioctls (decoded into
platform independent "change baud rate to 9600" etc) on the tty
in-band to the pty. I used in-band so this data stream could then be
piped via ssh etc)
--
Nick Craig-Wood
[email protected]