Matthias Welwarsky wrote:
> Hopefully ;-) We may still have a talk about the interface. kiss is fine
> to just get the data out of the kernel, however, the new code assumes
> that the driver supplies information about PTT and DCD state. Impossible
> with KISS, 6PACK via pty may be a solution, but 6PACK is much harder to
> implement on the driver side then kiss - I know that, I wrote the 6PACK
> driver for the TNC2 ;-)
I too don't think 6PACK is a good solution for this application.
6PACK is good where the 6PACK data flows over a "bandwidth limited
channel", i.e. over a serial link. pty's however are fast,
so we should get away with say an additional KISS frame informing
the stack about DCD, for example.
But ultimatively I'd like a frame oriented interface, one
I can for example sendto/recvfrom. And possibly an ioctl
to inform the kernel about the channel state.
> For sure you can go on with kiss and implement channel access on your
> own, but then the kernel won't be able to optimize the channel access
> strategy.
I know, and therefore I'd like a longer term solution.
But the issue is this: With the new EPP modem I'd like
to be able to do ECP, and transfer data with the DMA
controller. For this I need to be able to suspend
my driver during DMA. To do this I need a process context.
And this is infinitely more complex from the kernel space
than from user space, for no big benefit.
The same goes for Soundmodem. Being in userspace allows
me to use for example libm to calculate filter coefficients
and get a much more flexible solution basically for free.
Tom
