[RFC] Introduce ports.

[andrzej zaborowski]

Hi,

On 05/08/07, Jan Lübbe <jluebbe at lasnet.de> wrote:
> On Thu, 2007-08-02 at 17:06 +0200, andrzej zaborowski wrote:
> > The port is much like a tty, the term is used a lot in the TS 07.10
> > document. I was going through TS 07.10 and implementing the
> > multiplexing when I noticed that we will need to use some kind of port
> > notion in gsmd to be able to start and stop the multiplexing, without
> > going around though pty's. Pty's can be easily implemented on top of
> > the struct gsmd_port (e.g. for GPRS with pppd).
> >
> > It should be easy to switch to and from multiplexing mode in the AT
> > cmd parser with this. The uart fd is wrapped in a struct gsmd_port and
> > only this struct is used by atcmd.c. When the multiplexer is enabled,
> > each DLC will provide a (virtual) gsmd_port of its own and atcmd.c can
> > then be attached to one of these ports. The attached
> > src/gsmd/ts0710muxing.c is where I left off the multiplexer
> > implementation, if I can make the multiplexing work until Saturday I
> > wil
> > l post a patch under bug #90 (I will be away after Saturday).
> > Regards
>
> There is already a TS 07.10 implemetation in the kernel. See Harald
> Welte's message:
> http://lists.openmoko.org/pipermail/gsmd-devel/2007-July/000132.html
>
> It provides a TTY per DLC to userspace.
>
> This driver needs some more work though, it was ported from 2.4 for the
> OpenEZX project. The EZX GSM-Modem deviates somewhat from TS 07.10, so
> the differences should be factored out.

Ah, yes, now I see how it may be a better idea to do the multiplexing
in the kernel for performance reasons. I didn't notice that bug #90
was under "kernel" component rather than "gsmd" component.

I had a look at the OpenEZX version, it doesn't seem to deviate that
much from TS 07.10 but it implements (and assumes, in far too many
places) only features needed by that specific modem, e.g. only basic
frame format, while Ti Calypso uses only the advanced frames, so this
part can be taken from my patch, which is verified to work on the
Neo1973. I would also like to see a possibility to open/close new DLCs
through gsmd instead of having a hardcoded number of them, but I'm not
sure what interface we would use (ioctl? on what node? maybe the DLC 0
should also be exported to userspace and driven by gsmd, while the
kernel would *only* wrap and unwrap data from ttys into frames).

The struct gsmd_port idea is still a useful one I think. And I believe
having an additional TS 07.10 implementation in gsmd is also quite
crucial if gsmd has an ambition of being portable, although that's
much lower priority.

Regards