[alsa-devel] [RFC] tty (or char) bus?
![](https://secure.gravatar.com/avatar/76f692a58f1b377cdde5cbfe23090f81.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/25fc28cce58432338f7f7053f2edf6c6.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/7dd51d3db690d1d052c216b5a9e04c4a.jpg?s=120&d=mm&r=g)
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.
![](https://secure.gravatar.com/avatar/25fc28cce58432338f7f7053f2edf6c6.jpg?s=120&d=mm&r=g)
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
participants (3)
-
Janusz Krzysztofik
-
Samuel Thibault
-
Tilman Schmidt