Hi,
In my attempt to add support for contols to a voice modem codec sound
device driver, I found that in order to talk to the modem, it would be
convenient if I can get access to a tty device from inside the kernel in
a way similiar to that available form userspace. AFAICS, even if tty
lowlevel write() could be used unmodified, a convenient way of reading
characters from a tty is missing and should be implemented in a line
discipline. Please correct me if I am wrong.
OTOH, I found that some kind of abstraction layer for acccessing devices
over a tty could be convenient. Instead of allocating a new line
discipline for each specific device, sometimes found on a specific board
only, why not just create a new bus type?
Implemented as a line discipline, activated (hot-plugged) from userspace
with ldattach, that new bus adapter would give kernel level access to an
arbitrary device hanging off a tty. As the bus can be assumed
point-to-point, a single generic device could be registered
automatically in order to trigger that bus registerd drivers' probes
(vendor/model id queries, for example). If not enough, an ioctl and a
ldattach replacement could be provided for setting up a device id that
would match a driver id (something like inputattach does for N_MOUSE).
Once detected by a voice modem codec driver tty bus probe(), a codec
subdevice could then be registered with a sound card.
Please let me know if you like the idea. If not, please push me in a
better direction.
Many of the new code could be probably based on currently existing
drivers and line discplines. As I'm not familiar enough with the linux
kernel code, unlike most of you, so please give me some hints on what
specific drivers should I look at to get examples best matching my idea.
Thanks,
Janusz
Hello,
Janusz Krzysztofik, le Tue 14 Jul 2009 17:31:23 +0200, a ?crit :
> In my attempt to add support for contols to a voice modem codec sound
> device driver, I found that in order to talk to the modem, it would be
> convenient if I can get access to a tty device from inside the kernel in
> a way similiar to that available form userspace.
I agree.
> AFAICS, even if tty lowlevel write() could be used unmodified, a
> convenient way of reading characters from a tty is missing and should
> be implemented in a line discipline. Please correct me if I am wrong.
Have you seen the receive_buf line discipline hook? Indeed it's not a
read() operation as from userland, but at least you can get the data
from the tty that way.
> OTOH, I found that some kind of abstraction layer for acccessing devices
> over a tty could be convenient. Instead of allocating a new line
> discipline for each specific device, sometimes found on a specific board
> only, why not just create a new bus type?
I'd tend to agree with you, as I also have a use case for that: braille
& speech synthesis devices. However for now I haven't found a really
convincing argument why line disciplines aren't enough.
Samuel
Scripsit Samuel Thibault die 17.07.2009 19:54:
> Janusz Krzysztofik, le Tue 14 Jul 2009 17:31:23 +0200, a ?crit :
>> AFAICS, even if tty lowlevel write() could be used unmodified, a
>> convenient way of reading characters from a tty is missing and should
>> be implemented in a line discipline. Please correct me if I am wrong.
>
> Have you seen the receive_buf line discipline hook? Indeed it's not a
> read() operation as from userland, but at least you can get the data
> from the tty that way.
That's as it should be. A read() operation that sleeps until some data
is available isn't very useful in kernel mode, as it can only be used
if you have the ability to sleep. A callback function which runs your
code as soon as the data arrives is a much better fit, although of
course it requires a bit of rethinking.
>> OTOH, I found that some kind of abstraction layer for acccessing devices
>> over a tty could be convenient. Instead of allocating a new line
>> discipline for each specific device, sometimes found on a specific board
>> only, why not just create a new bus type?
>
> I'd tend to agree with you, as I also have a use case for that: braille
> & speech synthesis devices. However for now I haven't found a really
> convincing argument why line disciplines aren't enough.
I was in the same situation three years ago when I implemented the
ser_gigaset driver for an RS232 connected ISDN adapter, and found the
line discipline (LD) interface quite adequate once I had figured out
how to use it. The only inconvenience is how LDs are loaded and
attached to a serial interface, via the TIOCSETD ioctl, because you
need a userspace daemon which keeps the tty device open so that the
LD stays attached to it.
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
Tilman Schmidt, le Sun 19 Jul 2009 15:19:22 +0200, a ?crit :
> The only inconvenience is how LDs are loaded and attached to a serial
> interface, via the TIOCSETD ioctl, because you need a userspace daemon
> which keeps the tty device open so that the LD stays attached to it.
Yes, that's a burden for me also, while I could just tell my module to
use ttyS0 through parameters for instance.
Samuel